On Tue, Nov 8, 2022 at 7:22 AM Sebastian Huber
wrote:
>
> On 05.11.22 12:18, Richard Biener wrote:
> > On Fri, Nov 4, 2022 at 9:28 AM Sebastian Huber
> > wrote:
> >> Hello,
> >>
> >> even recent 32-bit architectures such as RISC-V do not support 64-bit
> >> atomic operations. Using -fprofile-up
I'm trying to validate a change to gcc/config/msp430/msp430.cc.
The cross-compiler builds as far as I can tell, but I hit a snag while
configuring libstdc++:
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:12334: configure-tar
On 08.11.22 11:25, Richard Biener wrote:
How do I get ((unsigned int *) &val) + 1 from tree addr?
It would be great to have a code example for the construction of the "if
(f()) f();".
I think for the function above we need to emit __atomic_fetch_add_8,
not the emulated form because we cannot in
On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
wrote:
>
> I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> The cross-compiler builds as far as I can tell, but I hit a snag while
> configuring libstdc++:
>
> checking for shl_load... configure: error: Link tests are not a
On Tue, 8 Nov 2022 at 12:37, Jonathan Wakely wrote:
>
> On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
> wrote:
> >
> > I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> > The cross-compiler builds as far as I can tell, but I hit a snag while
> > configuring libstdc++:
>
On Tue, Nov 8, 2022 at 1:00 PM Sebastian Huber
wrote:
>
> On 08.11.22 11:25, Richard Biener wrote:
> >> How do I get ((unsigned int *) &val) + 1 from tree addr?
> >>
> >> It would be great to have a code example for the construction of the "if
> >> (f()) f();".
> > I think for the function above w
Hi.
Tomorrow in the morning (UTC time), I'm going to migrate the documentation
to Sphinx. The final version of the branch can be seen here:
$ git fetch origin refs/users/marxin/heads/sphinx-final
$ git co FETCH_HEAD
URL: https://splichal.eu/gccsphinx-final/
TL;DR;
After the migration, people
> On 8 Nov 2022, at 13:55, Martin Liška wrote:
>
> Hi.
>
> Tomorrow in the morning (UTC time), I'm going to migrate the documentation
> to Sphinx. The final version of the branch can be seen here:
>
> $ git fetch origin refs/users/marxin/heads/sphinx-final
> $ git co FETCH_HEAD
>
> URL: http
On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
> even for snapshots? Pretty please? :)
I think we want snapshots to come out weekly even if the compiler or
documentation build fails, which makes anything involving a build as part
> On 9 Nov 2022, at 00:00, Joseph Myers wrote:
>
> On Tue, 8 Nov 2022, Sam James via Gcc wrote:
>
>> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
>> even for snapshots? Pretty please? :)
>
> I think we want snapshots to come out weekly even if the compiler or
> documentat
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
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 is a "help wanted" message. When I run GCC regression test on
loongarch64-linux-gnu, expect occasionally crashes with a segment fault.
The stack backtrace is like:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x70a35910 in TclpAlloc () from /usr/lib/libtcl8.6.
On Wed, Nov 9, 2022 at 1:09 AM Sam James via Gcc-patches
wrote:
>
>
>
> > On 9 Nov 2022, at 00:00, Joseph Myers wrote:
> >
> > On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> >
> >> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
> >> even for snapshots? Pretty please? :)
> >
> >
16 matches
Mail list logo
