On Jun 23, 2022, Alexandre Oliva wrote:
> Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a
> cross to aarch64-rtems6. Ok to install?
> Introduce -nostdlib++ option
Uhh, I went ahead and installed this. The earlier patch was approved if
nobody objected, and so, having
On Jun 23, 2022, Alexandre Oliva wrote:
> * aclocal.m4, configure, config.h.in: Rebuilt.
Dropped aclocal.m4 for the checkin, thanks to the ChangeLog checker.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU
On Jun 23, 2022, Alexandre Oliva wrote:
> for gcc/testsuite/ChangeLog
> * doc/sourcebuild.exp (Environment attributes): Document it.
Fixed two problems in the above, thanks for the ChangeLog checker. It's
.texi, and it belongs in gcc/ChangeLog.
--
Alexandre Oliva, happy hacker
On Jun 23, 2022, Alexandre Oliva wrote:
> *
> testsuite/experimental/filesystem/iterators/recursive_directory_itreator.cc
s/itreator/iterator/ for the checkin, thanks to the ChangeLog checker :-)
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi Segher,
Thanks for the comments.
on 2022/6/24 03:06, Segher Boessenkool wrote:
> Hi!
>
> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
>> As PR103353 shows, we may want to continue to expand a MMA built-in
>> function like a normal function, even if we have already emitted
>>
On Thu, Jun 23, 2022 at 2:24 PM Dimitar Dimitrov wrote:
>
> A few testcases were marked for avr target, which has no alignment
> requirements. But those tests in fact should filter for any
> target having __BIGGEST_ALIGNMENT__=1.
>
> A new effective target check is introduced:
Hello.
I have added support for naked functions on the OpenRISC 1200 target
it practically inhibits the generation of a function epilogue and
prologue and will warn about variables that might use the stack (to
prevent unintended code being generated).
As well added a table for attributes where
A few testcases were marked for avr target, which has no alignment
requirements. But those tests in fact should filter for any
target having __BIGGEST_ALIGNMENT__=1.
A new effective target check is introduced: no_alignment_constraints.
It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.
The gcc.dg/builtin-object-size-20.c test case assumes that the target
inserts padding between structure members. Obviously it fails for
targets which pack structures by default.
Split the cases into two tests, so that the ones requiring structure
padding can be skipped for default_packed
Epiphany, PRU, ARC and NDS32 may predefine __big_endian__ and
__little_endian__ macros. This leads to spurious warnings like:
gcc.dg/sso/memcpy-1.c:7: warning: "__little_endian__" redefined
Fix by renaming the macros in the test.
Ok for trunk?
gcc/testsuite/ChangeLog:
*
Some embedded targets do not pass any argv arguments. When argc is
zero, this causes spurious failures for lto/pr101868_0.c. Fix by
following the strategy in r0-114701-g2c49569ecea56d. Use a volatile
variable instead of argc to inject a runtime value into the test.
I validated the following:
This test spuriously fails on AVR with:
error: width of 'bitfield_c' exceeds its type
8-bit and 16-bit microcontrollers do not seem to be the target audience
for BTF file format. So the least intrusive fix is to simply skip the
test for them.
Ok for trunk?
gcc/testsuite/ChangeLog:
If target packs structures by default, the bitfield offset which the
tests validates must be adjusted to not include padding.
Ok for trunk?
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-bitfields-1.c: Adjust the checked offsets
for targets which pack structures by default.
On Thu, Jun 23, 2022 at 10:49:55PM +0200, Harald Anlauf wrote:
> > We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
> > instead of *q) and library change.
>
> this is quite an important change in the gfortran ABI, as it will
> require recompilation of (library) code
build_aggr_conv expects to run after reshape_init, which will usually have
filled out all the CONSTRUCTOR indexes; there's no reason to limit using
those to the case where the user gave an explicit designator.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105925
This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR. So set the flag when we see a designator rather
than
Hi Jakub,
Am 23.06.22 um 14:04 schrieb Jakub Jelinek via Gcc-patches:
Hi!
As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid
This patch by zhangjian to the Go frontend changes Sort_bindings to
return false if comparing a value to itself. Apparently some versions
of std::sort may pass elements at the same iterator location. This
fixes https://go.dev/issue/53483. Bootstrapped and ran Go testsuite
on
This patch to the Go frontend makes sure to unalias types when
creating hash/equality functions. This fixes
https://go.dev/issue/52846. There is a test case at
https://go.dev/cl/413694. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
On 6/23/22 11:06, Patrick Palka wrote:
Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in
On 6/23/22 10:48, Patrick Palka wrote:
The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated. In particular, it can happen for a
Hi!
On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that PR, without one
On Wed, 2022-06-22 at 18:34 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * common.opt (fdiagnostics-show-rules): New option.
> * diagnostic-format-json.cc
> (diagnostic_output_format_init_json):
> Fix up context->show_rules.
> * diagnostic-format-sarif.cc
>
On Thu, 23 Jun 2022 at 15:05, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva wrote:
> >>
> >> On Jun 22, 2022, Jonathan Wakely wrote:
> >>
> >> > There are other interactions between AT_CDCWD and ::openat not covered
> >>
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49
Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to
Hi Maciej:
Thanks for detail analysis and performance number report, I am concern
about this patch might let compiler schedule the fsflags/frflags with
other floating point instructions, and the major issue is we didn't
model fflags right in GCC as you mentioned in the first email.
So I think we
On Wed, 22 Jun 2022, David Malcolm via Gcc-patches wrote:
> extern bool emit_diagnostic (diagnostic_t, rich_location *, int,
>const char *, ...) ATTRIBUTE_GCC_DIAG(4,5);
> +extern bool emit_diagnostic (diagnostic_t, rich_location *,
> + const
On Thu, 23 Jun 2022 at 12:39, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
> > wrote:
>
> >> It was prompted by a target system with a non-random implementation of
> >> mkstemp, that returns a predictable
On Wed, Jun 22, 2022 at 11:03 PM Richard Biener
wrote:
>
> On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu wrote:
> >
> > On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> > wrote:
> > >
> > > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > When memchr is applied
Tested x86_64-linux, pushed to trunk.
-- >8 --
Although these tests use filesystem::remove_all to clean up, that fails
because it uses recursive_directory_iterator which is intentionally
bodged by the custom readdir defined in the test.
Just use POSIX rmdir to clean up. We don't need to use
Hi Jakub,
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
(1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
(2) chunk_size == 0: infinite loop
The (2) behavior is obviously not desired. This patch fixes this by changing
the chunk_size
Like we avoid various warnings for seemingly tautological expressions when
substituting a template, we should avoid warning for the implicit conversion
to bool in an if statement. I considered also doing this for the conditions
in loop expressions, but that seems unnecessary, as a loop condition
We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. It
seems we need to do this for -Waddress as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105885
gcc/cp/ChangeLog:
Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.
We
The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated. In particular, it can happen for a non-dependent
specialization of a nested
On Jun 23, 2022, Jonathan Wakely wrote:
> On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva wrote:
>>
>> On Jun 22, 2022, Jonathan Wakely wrote:
>>
>> > There are other interactions between AT_CDCWD and ::openat not covered
>> > by this patch. I this this also needs to check HAVE_OPENAT:
>>
>>
Hi,
this patch adds fnspecs for cxa_* functions in except.cc. Main goal is to make
modref to see proper side-effects of functions which may throw. So in general
we get
- cxa_allocate_exception
which gets the same annotations as malloc (since it is kind of same thing)
- cxa_free_exception
On Thu, 23 Jun 2022, Jan Hubicka wrote:
> Hi,
> this patch adds missing check to stmt_kills_ref_p for case that function
> is terminated by EH before call return value kills the ref. In the PR
> I tried to construct testcase but I don't know how to do that until I
> annotate EH code with fnspec
Hi,
this patch adds missing check to stmt_kills_ref_p for case that function
is terminated by EH before call return value kills the ref. In the PR
I tried to construct testcase but I don't know how to do that until I
annotate EH code with fnspec attributes which I will do in separate patch
and
On Thu, 9 Jun 2022, Maciej W. Rozycki wrote:
> I'm yet running some benchmarking to see if the use of UNSPEC_VOLATILEs
> makes any noticeable performance difference, but I suspect it does not as
> the compiler could not do much about the original multiple-instruction
> single RTL insns
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Pushed based on Jakub's approval.
Thanks,
Martin
PR c++/106062
gcc/ChangeLog:
* ubsan.cc (sanitize_unreachable_fn): Change order of calls
in order to initialize UBSAN built-ins.
On Jun 23, 2022, Jonathan Wakely wrote:
>> Regstrapped on x86_64-linux-gnu, also tested with a cross to
>> aarch64-rtems6. Ok to install?
> OK, thanks.
Sorry, I failed to refresh this one too.
Here's what I'm going to install:
libstdc++: xfail rename tests on rtems
From: Alexandre Oliva
On Jun 23, 2022, Jonathan Wakely wrote:
> On Thu, 23 Jun 2022 at 12:26, Alexandre Oliva via Libstdc++
> wrote:
>> I was using something like this internally. Regstrapped on
>> x86_64-linux-gnu, also tested with a cross to aarch64-rtems6. Ok to
>> install?
> OK, thanks.
Sorry, I goofed when
On Thu, 23 Jun 2022 at 13:36, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > Could this new arg be given a default value, so every caller doesn't
> > have to pass "" to it?
>
> > proc v3_check_preprocessor_condition { name cond {inc ""} } {
>
> Oh, nice, I didn't know
On Jun 23, 2022, Jonathan Wakely wrote:
> Could this new arg be given a default value, so every caller doesn't
> have to pass "" to it?
> proc v3_check_preprocessor_condition { name cond {inc ""} } {
Oh, nice, I didn't know about this convenient notation for default args
in tcl, and the one I
This implements garbage collection on locations within macro
expansions, when streaming out a CMI. When doing the reachability
walks, we now note which macro locations we need and then only write
those locations. The complication here is that every macro expansion
location has an independently
Hi!
As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex
In a reduction pair like:
typedef float T;
void
f1 (T *x)
{
T res1 = 0;
T res2 = 0;
for (int i = 0; i < 100; ++i)
{
res1 += x[i * 2];
res2 += x[i * 2 + 1];
}
x[0] = res1;
x[1] = res2;
}
it isn't easy to predict whether the initial
On Thu, Jun 23, 2022 at 12:51 PM Richard Sandiford via Gcc-patches
wrote:
>
> The fix for PR106019 regressed slsr-39.c for -m32 -march=cascadelake
> because we are now able to vectorise the code. (Whether the code model
> should be allowing that is a different question -- the vectorised code
>
On Thu, 23 Jun 2022 at 12:26, Alexandre Oliva via Libstdc++
wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
> > sebastian.hu...@embedded-brains.de> wrote:
>
> >> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
> >> > +}
On Thu, 23 Jun 2022 at 11:53, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > Which tests are failing? I might be able to point you to the cause
> > much faster than you can debug it yourself.
>
> With commit 7e2db5d102dd05ffa9c46b89616f7a700a9889f8 (current
>
On Jun 22, 2022, Jonathan Wakely wrote:
> On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
> wrote:
>> It was prompted by a target system with a non-random implementation of
>> mkstemp, that returns a predictable sequence of filenames and selects
>> the first one that isn't already
On Thu, 23 Jun 2022 at 12:21, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
> >> Would a patch to add:
> >>
> >> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
> >>
> >> to rename.cc tests
On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > There are other interactions between AT_CDCWD and ::openat not covered
> > by this patch. I this this also needs to check HAVE_OPENAT:
>
> Here's an updated version, tested with this additional
On 23/06/2022 13:33, Alexandre Oliva wrote:
Anyway... I was considering this xfail patch before, and I wonder if it
would still be appropriate to install something like it, narrowed down
to rtems < 6.1, or if it would be better to let it fail noisily so that
people look it up, find the fix
On Jun 22, 2022, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6. Ok to install?
The early wakeups are fixed for rtems6.1, so the same question raised at
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to
this one:
Tested x86_64-linux, pushed to trunk.
-- >8 --
This test uses std::log2 without including , but it doesn't need
to use it at all. Just get the number of digits from numeric_limits
instead.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_device/entropy.cc: Use
On Jun 23, 2022, Sebastian Huber wrote:
> On 23/06/2022 08:44, Sebastian Huber wrote:
>> http://devel.rtems.org/ticket/4669
Thanks!
> This problem should be fixed now in the RTEMS master branch.
Double thanks! I've applied the patch, and I haven't seen the fails any
more. It's a little too
On Thu, 23 Jun 2022 at 12:06, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > This could be done once in testsuite_fs.h as well.
>
> Done. Erhm, I posted the new revision of the patch for this thread in
> the last_write_time thread, so I'm posting the last_write_time
On Thu, 23 Jun 2022 at 12:05, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > And again, this could be a macro defined in testsuite_fs.h
>
> Done. (it depends on dg changes in the symlink patch)
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
>
On Thu, 23 Jun 2022 at 12:28, Jonathan Wakely wrote:
>
> On Thu, 23 Jun 2022 at 12:02, Alexandre Oliva wrote:
> >
> > On Jun 22, 2022, Jonathan Wakely wrote:
> >
> > > OK.
> >
> > > I'd like to clean this up so the tests don't rely on the "internal"
> > > HAVE_SYMLINK macro. We could add
On Thu, 23 Jun 2022 at 12:02, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > OK.
>
> > I'd like to clean this up so the tests don't rely on the "internal"
> > HAVE_SYMLINK macro. We could add something like this to
> > testsuite/util/testsuite_fs.h
>
> > #if
On Jun 22, 2022, Alexandre Oliva wrote:
> Yeah, I suppose that makes sense, it's beneficial for users to avoid the
> cognitive overload of dealing with equivalent options with different
> spellings. I'll swallow my dislike for the spelling and change the
> patch to use -nostdlib++.
Here's the
On Jun 23, 2022, Jonathan Wakely wrote:
> On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
> sebastian.hu...@embedded-brains.de> wrote:
>> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
>> > +} elseif { [istarget *-*-rtems*] } {
>> > + # Adding -Wl,--gc-sections would enable a
On Jun 23, 2022, Jonathan Wakely wrote:
> On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
>> Would a patch to add:
>>
>> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
>>
>> to rename.cc tests be acceptable?
> Yes, I think that's definitely the way to go.
The
On Jun 22, 2022, Jonathan Wakely wrote:
> There are other interactions between AT_CDCWD and ::openat not covered
> by this patch. I this this also needs to check HAVE_OPENAT:
Here's an updated version, tested with this additional change.
libstdc++: check for openat
From: Alexandre Oliva
On Jun 22, 2022, Jonathan Wakely wrote:
> This could be done once in testsuite_fs.h as well.
Done. Erhm, I posted the new revision of the patch for this thread in
the last_write_time thread, so I'm posting the last_write_time one here.
This one also depends on dg infrastructure added in the
On Jun 22, 2022, Jonathan Wakely wrote:
> And again, this could be a macro defined in testsuite_fs.h
Done. (it depends on dg changes in the symlink patch)
Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6. Ok to install?
libstdc++: testsuite: skip fs space tests
On Jun 22, 2022, Jonathan Wakely wrote:
> OK.
> I'd like to clean this up so the tests don't rely on the "internal"
> HAVE_SYMLINK macro. We could add something like this to
> testsuite/util/testsuite_fs.h
> #if defined(__MINGW32__) || defined(__MINGW64__) \
> || !defined
On Jun 22, 2022, Richard Sandiford wrote:
> Other selectors don't use CamelCase, so I guess it should be
> two_plus_gigs instead. There also needs to be an entry in
> sourcebuild.texi.
Thanks for the reminder, I keep forgetting about this.
> OK with those changes, thanks.
Here's what I'm
On Jun 22, 2022, Jonathan Wakely wrote:
> Which tests are failing? I might be able to point you to the cause
> much faster than you can debug it yourself.
With commit 7e2db5d102dd05ffa9c46b89616f7a700a9889f8 (current
refs/users/aoliva/heads/testme) I get:
FAIL:
The fix for PR106019 regressed slsr-39.c for -m32 -march=cascadelake
because we are now able to vectorise the code. (Whether the code model
should be allowing that is a different question -- the vectorised code
looked worse to me.)
The test runs at -O2 and predates vectorisation being enabled at
On Thu, 23 Jun 2022 at 05:41, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely wrote:
>
> > Otherwise, if rterms defines HAVE_DIRFD this function will return a
> > file descriptor and a filename (not a full path) but then
> > _Dir_base::openat doesn't use ::openat and so ignores the
On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
> This feels more and more like a case for xfail until it gets fixed in
> the kernel, where atomic filesystem operations belong :-(
>
> Would a patch to add:
>
> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
>
> to
On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:
> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
> > +} elseif { [istarget *-*-rtems*] } {
> > + # Adding -Wl,--gc-sections would enable a few more tests to
> > + # link, but all of
On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
+} elseif { [istarget *-*-rtems*] } {
+ # Adding -Wl,--gc-sections would enable a few more tests to
+ # link, but all of them fail at runtime anyway, because the
+ # io_context ctor calls pipe(), which always
On 23/06/2022 08:44, Sebastian Huber wrote:
On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber
wrote:
The clock_nanosleep() uses the coarse resolution which may give a time
before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to
On Wed, Jun 22, 2022 at 1:39 PM Roger Sayle wrote:
>
>
> This patch addresses PR target/105930 which is an ia32 stack frame size
> regression in high-register pressure XOR-rich cryptography functions
> reported by Linus Torvalds. The underlying problem is once the limited
> number of registers
On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber wrote:
The clock_nanosleep() uses the coarse resolution which may give a time
before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.
I
On Jun 22, 2022, Jonathan Wakely wrote:
> "If the old argument and the new argument resolve to either the same
> existing directory entry or different directory entries for the same
> existing file, rename() shall return successfully and perform no other
> action." and "If the link named by the
On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu wrote:
>
> On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> wrote:
> >
> > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > When memchr is applied on a constant string of no more than the bytes of
> > > a word, inline memchr
82 matches
Mail list logo
