I noticed whilst working on another issue that in diagnostic-show-locus
within the quoted source lines and the annotation underlines that when
we're showing highlight-{a,b} that we emit
start-colorization-code, character, end-colorization-code
per *character*, rather than just when the colorizati
Hello world,
I have just committed the attached patch as obvious and simple
after regression-testing. Will backport to gcc 15 soonish.
This fixes a 15/16 regression where the code was looking at
the typespec of the symbol which we don't set if there is
a RESULT clause.
Thanks to Harald for poin
> The CI shows some scan failures in vls/avg-[456].c and
> widen/vec-avg-rv32gcv.c.
Oops, I should run all test locally without additional failures before sent
out, let me double check about it.
> Also, the lint check complains about this line:
Sure.
Pan
-Original Message-
From: Robi
On Fri, 30 May 2025, Qing Zhao wrote:
> There is only one last_field for a structure type, but there might
> be multiple last_fields for a union type, therefore we should ORed
> the result of TYPE_INCLUDES_FLEXARRAY for multiple last_fields of
> a union type.
>
> The patch has been bootstrapped a
Adding a test for behavior of the ostream operator and the formatting
with empty chron-spec for the chrono types. This commit covers calendar
types.
libstdc++-v3/ChangeLog:
* testsuite/std/time/format/empty_spec.cc: New test.
---
Tested on x86_64-linux. OK for trunk?
.../testsuite/std/t
On Thu, May 29, 2025 at 10:38 PM Jonathan Wakely wrote:
> The current overload set for __unique_copy handles three cases:
>
> - The input range uses forward iterators, the output range does not.
> This is the simplest case, and can just compare adjacent elements of
> the input range.
>
> - Ne
On 5/29/25 10:07, Tomasz Kaminski wrote:
On Thu, May 29, 2025 at 9:23 AM Tomasz Kaminski wrote:
On Mon, May 26, 2025 at 4:13 PM Luc Grosheintz
wrote:
Implements the remaining parts of layout_left and layout_right; and all
of layout_stride.
The implementation of layout_stride::mapping
Since last patch introduced get_fr2vr_cost () to get the correct cost to move
data from a floating-point to a vector register, this patch replaces existing
uses of the constant FR2VR.
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (costs::adjust_stmt_cost): Replace
FR2VR with
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a vec_duplicate into a plus-mult or minus-mult RTL instruction.
Before this patch, we have two instructions, e.g.:
vfmv.v.fv6,fa0
vfmadd.vv v9,v6,v7
After, we get only one:
vfmadd.vf
Similar to the avg_floor, the avg_ceil has the rounding mode
towards +inf, while the vaadd.vv has the rnu which totally match
the sematics. From RVV spec, the fixed vaadd.vv with rnu,
The CI shows some scan failures in vls/avg-[456].c and widen/vec-avg-rv32gcv.c.
Also, the lint check complains
On 29/05/25 9:05 pm, Segher Boessenkool wrote:
>> +#define _AMO_LD_INCREMENT(NAME, TYPE, OPCODE, FC) \
>> +static __inline__ TYPE
>> \
>> +NAME (TYPE *_PTR) \
>> +{
On Fri, 30 May 2025, Nathaniel Shead wrote:
> On Wed, May 28, 2025 at 02:14:06PM -0400, Patrick Palka wrote:
> > On Tue, 27 May 2025, Nathaniel Shead wrote:
> >
> > > On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > > > On Fri, 8 Nov 2024, Nathaniel Shead wrote:
> > > >
> > > >
On Fri, 30 May 2025, Patrick Palka wrote:
> On Fri, 30 May 2025, Nathaniel Shead wrote:
>
> > On Wed, May 28, 2025 at 02:14:06PM -0400, Patrick Palka wrote:
> > > On Tue, 27 May 2025, Nathaniel Shead wrote:
> > >
> > > > On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > > > > On
Hi, Richard,
Really appreciate for your suggestions.
> On May 30, 2025, at 05:22, Richard Biener wrote:
>
> On Fri, May 23, 2025 at 10:49 PM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> Thanks a lot for your comments and questions.
>> Please see my answers embedded below:
>>
>>> On May 19, 202
On Thu, May 29, 2025 at 03:07:34PM -0500, Peter Bergner wrote:
> On 5/29/25 5:35 AM, Segher Boessenkool wrote:
> >
> > Add yourself to suthors as well?
>
> Agreed. Just add your name/email address directly under mine, like so:
>
> 2025-05-29 Peter Bergner
> Jeevitha Palanisamy
Li
On Thu, 29 May 2025 at 12:12, Jonathan Wakely wrote:
>
> This series complete Tom's work to refactor the C++20 atomic wait/notify
> code, and includes several follow-up patches from me. The goal is to
> move the core implementation pieces into libstdc++.so instead of
> defining everything inline i
On Fri, May 23, 2025 at 10:49 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> Thanks a lot for your comments and questions.
> Please see my answers embedded below:
>
> > On May 19, 2025, at 06:44, Richard Biener
> > wrote:
> >
> > On Fri, May 16, 2025 at 3:34 PM Qing Zhao wrote:
> >>
> >> Control this
On 5/29/25 09:23, Tomasz Kaminski wrote:
On Mon, May 26, 2025 at 4:13 PM Luc Grosheintz
wrote:
Implements the remaining parts of layout_left and layout_right; and all
of layout_stride.
The implementation of layout_stride::mapping::is_exhaustive applies
the following change to the standard:
On Fri, May 30, 2025 at 12:01 PM Luc Grosheintz
wrote:
>
>
> On 5/29/25 10:07, Tomasz Kaminski wrote:
> > On Thu, May 29, 2025 at 9:23 AM Tomasz Kaminski
> wrote:
> >
> >>
> >>
> >>
> >> On Mon, May 26, 2025 at 4:13 PM Luc Grosheintz <
> luc.groshei...@gmail.com>
> >> wrote:
> >>
> >>> Implement
Hi Paul-Antoine,
overall the patch looks reasonable to me now, provided the fr2vr followup.
BTW it's the late-combine pass that performs the optimization, not the combine
pass. You might still want to fix this in the commit message.
Please CC patchworks...@rivosinc.com for the next version
libstdc++-v3/ChangeLog:
* include/std/mdspan(__mdspan::_ExtentsStorage): Change name
of private member _M_dynamic_extens to _M_dyn_exts.
* include/std/mdspan(extents): Change name of private member
from _M_dynamic_extents to _M_exts.
* include/std/mdspan: Fi
The discussion for v4 is here:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061665.html
The non-trivial changes are:
* Fixed bug in __offset that called m(0...) even for empty extents; added a
test.
* Fixed buggy tests for class mandates.
* Fix layout_stride::is_{,always_}exhaustive
[mdspan.layout.left.cons] of N4950 states that this ctor is not
noexcept. Since, all other ctors of layout_left, layout_right or
layout_stride are noexcept, the choice was made, based on
[res.on.exception.handling], to make this ctor noexcept.
Two other major standard library implementations make
Implements the tests for layout_stride and for the features of the other
two layouts that depend on layout_stride.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_stride.
* testsuite/23_containers/mdspan/layouts/c
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left): New class.
* src/c++23/std.cc.in: Add layout_left.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 306 +++
Implements a suite of tests for the currently implemented parts of
layout_left. The individual tests are templated over the layout type, to
allow reuse as more layouts are added.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: New test.
* tes
Adds tests for layout_right and for the parts of layout_left that depend
on layout_right.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_right.
* testsuite/23_containers/mdspan/layouts/ctors.cc: Add tests for
Implement the parts of layout_left that depend on layout_right; and the
parts of layout_right that don't depend on layout_stride.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_right): New class.
* src/c++23/std.cc.in: Add layout_right.
Signed-off-by: Luc Grosheintz
---
l
Implements the remaining parts of layout_left and layout_right; and all
of layout_stride.
The implementation of layout_stride::mapping::is_exhaustive applies
the following change to the standard:
4266. layout_stride::mapping should treat empty mappings as exhaustive
https://cplusplus.github.io
Am Donnerstag, dem 29.05.2025 um 20:57 + schrieb Joseph Myers:
> On Thu, 29 May 2025, Martin Uecker wrote:
>
> > get_aka_type will create a new type for diagnostics, but for tagged
> > types
> > attributes will then be ignored with a warning. This can lead to
> > reentering
> >
On Fri, 30 May 2025, Martin Uecker wrote:
> c: fix ICE related to tagged types with attributes in diagnostics
> [PR120380]
>
> get_aka_type will create a new type for diagnostics, but for tagged types
> attributes will then be ignored with a warning. This can lead to
> reenteri
From: Kwok Cheung Yeung
libgomp/
* testsuite/libgomp.c++/target-std__cmath.C: New.
* testsuite/libgomp.c++/target-std__complex.C: Likewise.
* testsuite/libgomp.c++/target-std__numbers.C: Likewise.
---
.../testsuite/libgomp.c++/target-std__cmath.C | 340 ++
Dear all,
here's a patch fixing the handling of parameter inquiries of
constant complex arrays. It profits from previous fixes for
inquiries of substrings and essentially adds only the simplification
of %re/%im applies to complex arrays - and fixes a minor frontend
memleak encountered on the way
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
>
> here's a patch fixing the handling of parameter inquiries of
> constant complex arrays. It profits from previous fixes for
> inquiries of substrings and essentially adds only the simplification
> of %re/%im applies to complex arra
Thanks.
Pushed to trunk.
And will pushed to GCC14 after 2-3 weeks. Is that okay?
Qing
> On May 30, 2025, at 09:25, Joseph Myers wrote:
>
> On Fri, 30 May 2025, Qing Zhao wrote:
>
>> There is only one last_field for a structure type, but there might
>> be multiple last_fields for a union type,
On Fri, 30 May 2025, Qing Zhao wrote:
> Thanks.
> Pushed to trunk.
> And will pushed to GCC14 after 2-3 weeks. Is that okay?
Subject to applying to GCC 15 before GCC 14 (and testing on each release
branch before applying it there), yes unless other release managers
express concerns. (There is
On Fri, 30 May 2025, Qing Zhao wrote:
> Thanks.
> Pushed to trunk.
> And will pushed to GCC14 after 2-3 weeks. Is that okay?
As with the other patch, subject to applying to GCC 15 before GCC 14 (and
testing on each release branch before applying it there), yes unless other
release managers exp
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Nathaniel shared a more extensive test, which revealed more needed fixes.
PR c++/113563
gcc/cp/ChangeLog:
* lambda.cc (lambda_capture_field_type): Handle 'this' normally.
(build_capture_proxy): Special-case 'this'
The following makes sure we are not lowering single-element interleaving
schemes in a way that defeats load vectorizing later but allows the
VMAT_ELEMENTWISE fallback to be used.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120457
* tree-vect-s
On 5/30/25 19:44, Steve Kargl wrote:
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
here's a patch fixing the handling of parameter inquiries of
constant complex arrays. It profits from previous fixes for
inquiries of substrings and essentially adds only the simplification
of %
On Fri, May 30, 2025 at 11:30 AM Jan Hubicka wrote:
>
> Hi,
> > >
> > > Hi,
> > >
> > > the attached Ada testcase compiled with -O2 -gnatn makes the compiler
> > > crash in
> > > vect_can_force_dr_alignment_p during SLP vectorization:
> > >
> > > if (decl_in_symtab_p (decl)
> > > && !symt
On 5/29/25 10:06, Tomasz Kaminski wrote:
On Thu, May 29, 2025 at 9:49 AM Tomasz Kaminski wrote:
On Mon, May 26, 2025 at 4:25 PM Luc Grosheintz
wrote:
Implements the tests for layout_stride and for the features of the other
two layouts that depend on layout_stride.
libstdc++-v3/ChangeL
On 5/28/25 14:49, Tomasz Kaminski wrote:
On Mon, May 26, 2025 at 4:21 PM Luc Grosheintz
wrote:
Implements a suite of tests for the currently implemented parts of
layout_left. The individual tests are templated over the layout type, to
allow reuse as more layouts are added.
libstdc++-v3/Cha
From: Waffl3x
libgomp/ChangeLog:
* testsuite/libgomp.c++/target-flex-10.C: New test.
* testsuite/libgomp.c++/target-flex-100.C: New test.
* testsuite/libgomp.c++/target-flex-101.C: New test.
* testsuite/libgomp.c++/target-flex-11.C: New test.
* testsuite/l
... to avoid running into ICEs per PR119835, until that's resolved properly.
PR middle-end/119835
gcc/
* tree-nrv.cc (pass_nrv::execute): Defuse 'RESULT_DECL' check.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:
'#pragma GCC optimize
libgomp/
* testsuite/libgomp.c++/target-std__array-concurrent-usm.C: New.
* testsuite/libgomp.c++/target-std__array-concurrent.C: Adjust.
* testsuite/libgomp.c++/target-std__bitset-concurrent-usm.C: New.
* testsuite/libgomp.c++/target-std__bitset-concurrent.C
From: Kwok Cheung Yeung
libgomp/
* testsuite/libgomp.c++/target-std__array-concurrent.C: New.
* testsuite/libgomp.c++/target-std__bitset-concurrent.C: Likewise.
* testsuite/libgomp.c++/target-std__deque-concurrent.C: Likewise.
* testsuite/libgomp.c++/target-std__f
libgomp/
* testsuite/libgomp.c++/target-std__valarray-1.C: New.
* testsuite/libgomp.c++/target-std__valarray-1.output: Likewise.
---
.../libgomp.c++/target-std__valarray-1.C | 179 ++
.../libgomp.c++/target-std__valarray-1.output | 22 +++
2 files chan
Hi,
> >
> > Hi,
> >
> > the attached Ada testcase compiled with -O2 -gnatn makes the compiler crash
> > in
> > vect_can_force_dr_alignment_p during SLP vectorization:
> >
> > if (decl_in_symtab_p (decl)
> > && !symtab_node::get (decl)->can_increase_alignment_p ())
> > return false;
> >
The following fixes conditional store elimination and store motion
so they consider stores to STRING_CSTs as trapping.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120341
* tree-ssa-loop-im.cc (can_sm_ref_p): STRING_CSTs are readonly.
*
On Fri, May 30, 2025 at 1:55 PM Jonathan Wakely wrote:
> On Fri, 30 May 2025 at 10:38, Tomasz Kamiński wrote:
> >
> > Adding a test for behavior of the ostream operator and the formatting
> > with empty chron-spec for the chrono types. This commit covers calendar
> > types.
> >
> > libstdc++-v3/
When doing early break vectorization of a loop with a conditional
reduction the epilog creation code is confused as to before which exit
to insert the conditional reduction induction IV update. The
following make sure this is done before the main IV exit.
Bootstrapped and tested on x86_64-unknown
On Fri, 30 May 2025 at 15:26, Tomasz Kaminski wrote:
>
>
>
> On Fri, May 30, 2025 at 1:55 PM Jonathan Wakely wrote:
>>
>> On Fri, 30 May 2025 at 10:38, Tomasz Kamiński wrote:
>> >
>> > Adding a test for behavior of the ostream operator and the formatting
>> > with empty chron-spec for the chrono
Tested on x86_64-darwin, OK for trunk?
thanks
Iain
--- 8< ---
These were omitted there as an oversight, most of the error handling
for the coroutines code is specific rather than using generic %qE etc.
gcc/cp/ChangeLog:
* error.cc (dump_expr): Add co_await, co_yield and co_return.
Sign
Tested on x86_64-darwin (but does need the addition of the coroutine
keywords to dump_expr), OK for trunk?
Thanks,
Iain
--- 8< ---
We checked that the coroutine expressions were not suitable for
constexpr, but did not emit and error when needed.
PR c++/118903
gcc/cp/ChangeLog:
> On Fri, May 30, 2025 at 11:30 AM Jan Hubicka wrote:
> >
> > Hi,
> > > >
> > > > Hi,
> > > >
> > > > the attached Ada testcase compiled with -O2 -gnatn makes the compiler
> > > > crash in
> > > > vect_can_force_dr_alignment_p during SLP vectorization:
> > > >
> > > > if (decl_in_symtab_p (decl
small typo, missing n at the end of function.
Pushed as obvious after a bootstrap/test.
gcc/ChangeLog:
* passes.cc (execute_all_ipa_transforms): Fix typo in
commenet.
Signed-off-by: Andrew Pinski
---
gcc/passes.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
+CC gcc-patches
On 5/30/25 14:04, Vineet Gupta wrote:
> Hi Jeff, Richard
>
> As part of RISC-V FRM mode switching improvements, I'm running into a behavior
> in late_combine2 where it is eliminating FRM save/restores when it is desired
> to
> keep them.
>
> I'm pasting snippet of RTL dumps, could
> On May 30, 2025, at 12:52, Joseph Myers wrote:
>
> On Fri, 30 May 2025, Qing Zhao wrote:
>
>> Thanks.
>> Pushed to trunk.
>> And will pushed to GCC14 after 2-3 weeks. Is that okay?
>
> As with the other patch, subject to applying to GCC 15 before GCC 14 (and
> testing on each release bra
> On May 30, 2025, at 12:52, Joseph Myers wrote:
>
> On Fri, 30 May 2025, Qing Zhao wrote:
>
>> Thanks.
>> Pushed to trunk.
>> And will pushed to GCC14 after 2-3 weeks. Is that okay?
>
> Subject to applying to GCC 15 before GCC 14 (and testing on each release
> branch before applying it th
Thanks.
Pushed to trunk.
And will pushed to GCC14 after 2-3 weeks. Is that okay?
Qing
> On May 29, 2025, at 17:04, Joseph Myers wrote:
>
> On Thu, 29 May 2025, Qing Zhao wrote:
>
>> The root cause of the bug is: the TYPE_INCLUDES_FLEXARRAY marking of the
>> structure type is not copied to its
On Thu, 29 May 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Various places were still making assumptions that we could get to the 'this'
> capture through current_class_ref in a lambda op(), which is incorrect for
> an explicit object op().
>
>
The documentation of which standard C library facilities (headers) are
provided by GCC, as being those required of freestanding
implementations, is reasonably accurate for C99 and before (if you
ignore the provision of for non-GNU targets). It's less
accurate for C11, since we provide although t
On Thu, May 29, 2025 at 1:05 AM wrote:
>
> From: Dhruv Chawla
>
> This patch folds the following patterns:
> - max (a, add (a, b)) -> [sum, ovf] = addo (a, b); !ovf ? sum : a
> - max (a, sub (a, b)) -> [sum, ovf] = subo (a, b); !ovf ? a : sum
> - min (a, add (a, b)) -> [sum, ovf] = addo (a, b); !
On Fri, 30 May 2025 at 10:38, Tomasz Kamiński wrote:
>
> Adding a test for behavior of the ostream operator and the formatting
> with empty chron-spec for the chrono types. This commit covers calendar
> types.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/std/time/format/empty_spec.cc: New t
I have now committed the second declare mapper patch, submitted
by Julian at
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629367.html
again it is based in the associated OG15 commit (kudos to all doing the
rediffs):
69fd51954fc OpenMP: Support OpenMP 5.0 "declare mapper" directives
> The CI shows some scan failures in vls/avg-[456].c and
> widen/vec-avg-rv32gcv.c.
Looks like the CI cannot tell patch series? There are 3 patches and the CI will
run for each one.
Of course, the first one will have scan failure due to expanding change, but
the second one reconciles them.
Fin
Hi Robin,
On 30/05/2025 10:18, Robin Dapp wrote:
BTW it's the late-combine pass that performs the optimization, not the
combine pass. You might still want to fix this in the commit message.
I updated the commit message.
Actually, it depends whether or not the vec_duplicate is hoisted to the
Looks like the CI cannot tell patch series? There are 3 patches and the CI
will run for each one.
Of course, the first one will have scan failure due to expanding change, but
the second one reconciles them.
Finally the third one will have all test passed as below, I think it
indicates all test
> Yes, you're right. I have looked at it again an hour ago and came to the
> same
> conclusion. I thought this worked before and it would only show results for
> the last patch of the series?
> Anyway, the series is OK.
Thanks Robin, will commit it with the format issue fixed after test is OK
The autoconf macro PKG_CHECK_MODULES defined in config/pkg.m4 is used in
binutils/gdb, but not in GCC. That macro uses the obsolete AC_TRY_LINK[1].
Update the code to use AC_LINK_IFELSE as documented by autoconf.
Regenerating all autotool files in both trees shows no difference.
[1]
https://www
Attached patch adds omp_target_memset and omp_target_memset_async
permitting to set (potentially large) data on the device to a
certain value - in particular to '\0'.
It uses 'memset' on the host (and for shared memory, e.g. via
requires unified_shared_memory/self_maps). For nvptx, cuMemsetD8
is
Update HTML output so that it renders highlight-a vs highlight-b
via tags in the message itself, in the quoted source line,
in the underlines, and in the labels and their vertical bars.
Example output can be seen at:
https://dmalcolm.fedorapeople.org/gcc/2025-05-28/diagnostic-ranges.c.html
Suc
In or1k structs are returned from functions using the memory address
passed in r3. In the current version of GCC the struct stores changed
from r11 (the return value) to r3 the incoming memory address. Both of
are valid.
Adjust the test to match what GCC is producing now.
gcc/testsuite/ChangeLo
The -mcmodel=large option was originally added to handle generation of
large binaries with large PLTs. However, when compiling the Linux
kernel with allyesconfig the output binary is so large that the jump
instruction 26-bit immediate is not large enough to store the jump
offset to some symbols wh
From: Pan Li
Inspired by the avg_ceil patches, notice there were even more
lines too long from autovec.md. So fix that format issues.
gcc/ChangeLog:
* config/riscv/autovec.md: Fix line too long for sorts
of pattern.
Signed-off-by: Pan Li
---
gcc/config/riscv/autovec.md | 54
This is a follow up to the patch set starting at
https://gcc.gnu.org/pipermail/gcc-patches/2014-April/386650.html.
Currently TODO_verify_{il,all} is set by a few passes as TODOs afterwards but
we don't need to do that any more. Those were mostly removed back in
https://gcc.gnu.org/pipermail/gcc-p
I've lost track of the number of rewrites to this patch, but I think it is V7.
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
extern double __ieee754_acos (double);
double
__acospi (double x)
{
double ret = __ieee754_a
On Thu, May 22, 2025 at 02:17:41PM +0530, Surya Kumari Jangala wrote:
> Hi Mike,
> The source code changes are missing.
Whoops. I just posted a completely new patch.
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685233.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 0143
On 5/30/25 16:36, Tobias Burnus wrote:
Attached patch adds omp_target_memset and omp_target_memset_async
permitting to set (potentially large) data on the device to a
certain value - in particular to '\0'.
It uses 'memset' on the host (and for shared memory, e.g. via
requires unified_shared_memo
80 matches
Mail list logo
