Re: [PATCH] libstdc++-v3: check for openat

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 file > descriptor, and needs a full path. Yuck. It does. This

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

On Jun 22, 2022, Jonathan Wakely wrote: > P.S. there's a typo in the Subject: "symlnks" not "symlinks". I don't > know if you intend to use that as the Git commit summary line. Thanks, I would have, fixed. I ended up introducing the feature abstraction macros in testsuite_fs.h, so I'll shortly

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

On Jun 22, 2022, Jonathan Wakely wrote: > On Wed, 22 Jun 2022 at 08:02, Alexandre Oliva via Libstdc++ > wrote: >> >> Hello, Sebastian, >> >> On Jun 22, 2022, Sebastian Huber wrote: >> >> > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote: >> >> rtems6's rename() implementation

[PATCH] Improve reg_or_subregno to return INVALID_REGNUM when the subreg of memory is processed.

Hi: This is follow-up to [1], return INVALID_REGNUM instead of gcc_assert, also adjust some conditions guarded for reg_or_subregno. >OK, but I think that reg_or_subregno should be improved to return >INVALID_REGNUM when the subreg of memory is processed. > >Thanks, >Uros. [1]

[pushed] c++: tweak deduction with auto template parms

While looking at PR105964 I noticed that we were unnecessarily repeating the deduction loop because of seeing a non-type parameter with type 'auto'. It is indeed dependent, but not on any other deductions. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * pt.cc

[pushed] c++: dependence of baselink [PR105964]

helper::c isn't dependent just because we haven't deduced its return type yet. type_dependent_expression_p already knows how to deal with that for bare FUNCTION_DECL, but needs to learn to look through a BASELINK. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105964

[PATCH] Fix typo

Fix typo and commit as obvious. Signed-off-by: Xionghu Luo gcc/ChangeLog: * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): Fix typo. * tree-ssa-loop-ivopts.cc (struct iv_cand): Likewise. * tree-switch-conversion.h: Likewise. --- gcc/cgraph.cc

[PATCH] Fix ICE when multiple speculative targets are expanded in different ltrans unit [PR93318]

There is a corner case for speculative multiple targets, that if speculative edges are streamed to different ltrans units, and then edges are expanded in one ltrans unit but the speculative property is not cleared by resolve_speculation in other ltrans unit finally cause ICE. This patch fixes

PING^1 [PATCH] inline: Rebuild target option node for caller [PR105459]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596212.html BR, Kewen on 2022/6/6 14:20, Kewen.Lin via Gcc-patches wrote: > Hi, > > PR105459 exposes one issue in inline_call handling that when it > decides to copy FP flags from callee to caller and rebuild the >

PING^2 [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html BR, Kewen >> Hi, >> >> 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.

PING^2 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html BR, Kewen >> Hi, >> >> As PR104482 shown, it's one regression about the handlings when >> the argument number is more than the one of built-in function >> prototype. The new bif support only catches the case that

PING^2 [PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html BR, Kewen > on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> PR105485 exposes that new builtin function framework doesn't handle >> unresolved overloaded builtin function well. With new builtin >>

RE: gcc-patches@gcc.gnu.org

<>

Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

On Jun 22, 2022, Jonathan Wakely wrote: > It looks like it would be possible for this to livelock. True > The current > implementation will fail with an error in that case, rather than > getting stuck forever in a loop. In the equivalent livelock scenario, newly-added dir entries are added to

Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

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. -- Alexandre Oliva, happy hacker

Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

On Jun 22, 2022, Sebastian Huber wrote: > The clock_nanosleep() uses the coarse resolution Thanks for looking into this. So, is it missing a rounding-up to ensure the sleep time is >= the requested time, or is it even more elaborate than that? -- Alexandre Oliva, happy hacker

Re: [PATCH] Introduce -nolibstdc++ option

On Wed, Jun 22, 2022 at 4:29 PM Alexandre Oliva wrote: > > On Jun 22, 2022, Iain Sandoe wrote: > > > It makes some sense to have the option named -nostdlib++ if a target > > might add multiple libs (and/or make other changes) for linking C++. > > if it was nostdlibc++, I'd agree. lib++ is not

Re: [PATCH] Introduce -nolibstdc++ option

On Jun 22, 2022, Iain Sandoe wrote: > It makes some sense to have the option named -nostdlib++ if a target > might add multiple libs (and/or make other changes) for linking C++. if it was nostdlibc++, I'd agree. lib++ is not something that brings C++ to (my) mind. > (so, fo example, if

[PATCH 09/12] Add json frontend

This patch adds a new json frontend: json-replayer, which the gcc driver can invoke on .json files saved with -fdiagnostics-format=json-file. gcc/ChangeLog: * json/Make-lang.in: New file. * json/config-lang.in: New file. * json/json-frontend.cc: New file. *

[PATCH 04/12] json: add json parsing support

This patch implements JSON parsing support. It's based on the parsing parts of the patch I posted here: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-08/msg00417.html with the parsing moved to a separate source file and header, and heavily rewritten to capture source location information for

[PATCH 12/12] Work-in-progress of path remapping

This work-in-progress hacks up the file_cache code in input.cc so that it can have an optional path remapper, which can map e.g. paths in a .sarif file to paths relative to that .sarif file, so that the sarif-replayer can locate and display sources. gcc/ChangeLog: * input.cc

[PATCH 06/12] prune.exp: move multiline-handling to before other pruning

Doing so allows for multiline directives to contain things like "note: " which would otherwise already have been pruned. gcc/testsuite/ChangeLog: * lib/prune.exp (prune_gcc_output): Move multiline-handling to before other pruning. Signed-off-by: David Malcolm ---

[PATCH 11/12] Fixups to diagnostic-format-sarif.cc

I believe these are needed by one of the rule-handling patches. gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_builder::sarif_builder): Defer population of m_driver_obj until... (sarif_builder::make_tool_object): ...here.

[PATCH 08/12] Add json-reader.h/cc

This patch adds classes that better integrate the JSON parser with GCC's diagnostic subsystem (e.g. line_maps). gcc/ChangeLog: * json-reader.cc: New file. * json-reader.h: New file. Signed-off-by: David Malcolm --- gcc/json-reader.cc | 122

[PATCH 07/12] Add deferred-locations.h/cc

libcpp requires locations to be created as if by a tokenizer, creating them by filename, in ascending order of line/column. This patch adds support classes that allow the creation of locations in arbitrary orders, by deferring all location creation, grouping things up by filename/line, and then

[PATCH 02/12] diagnostics: associate rules with plugins in SARIF output

gcc/ChangeLog: * diagnostic-client-data-hooks.h (class diagnostic_client_plugin_info): Move to... * diagnostic-client-plugin.h: ...this new file. * diagnostic-format-sarif.cc: Include "diagnostic-client-plugin.h". (class sarif_tool_component): New class.

[PATCH 00/12] RFC: Replay of serialized diagnostics

We currently have a couple of formats into which our diagnostics can be serialized: (a) gcc's own json format and (b) SARIF, via: -fdiagnostics-format=json-stderr (and -fdiagnostics-format=json) -fdiagnostics-format=json-file -fdiagnostics-format=sarif-stderr

[PATCH 01/12] diagnostics: add ability to associate diagnostics with rules from coding standards

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 (diagnostic_output_format_init_sarif): Likewise. *

[PATCH 05/12] Placeholder libcpp fixups

Obviously this isn't quite ready for trunk yet. libcpp/ChangeLog: * include/line-map.h (rich_location::maybe_add_fixit): Make public. * line-map.cc (linemap_add): Hack away assertion about LC_RENAME for now. Signed-off-by: David Malcolm ---

[PATCH 03/12] Add more emit_diagnostic overloads

gcc/ChangeLog: * diagnostic-core.h (emit_diagnostic): New overload. (emit_diagnostic_valist): New overload. * diagnostic.cc (emit_diagnostic): New overload. (emit_diagnostic_valist): New overload. Signed-off-by: David Malcolm --- gcc/diagnostic-core.h | 7

[pushed] c++: class scope function lookup [PR105908]

In r12-1273 for PR91706, I removed the code in get_class_binding that stripped BASELINK. This testcase demonstrates that we still need to strip it in outer_binding before putting the overload set in IDENTIFIER_BINDING, for compatibility with bindings added directly for declarations. Tested

Re: [PATCH] gcc/configure.ac: fix --enable-fixed-point enablement [PR34422]

Hello, Eric, On Jun 21, 2022, Eric Gallager wrote: > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596654.html > (cc-ing the build machinery maintainers listed in MAINTAINERS this time) Thanks > On Tue, Jun 14, 2022 at 3:51 PM Eric Gallager wrote: >> So, in investigating PR

Re: [PATCH] Introduce -nolibstdc++ option

> On 22 Jun 2022, at 01:36, Alexandre Oliva via Gcc-patches > wrote: > > On Jun 21, 2022, Fangrui Song wrote: > >> Is this similar to clang -nostdlib++ ? >> When libstdc++ is selected, clang -nostdlib++ removes -lstdc++. > > Sounds like they're the same indeed, but the clang option you

[r13-1203 Regression] FAIL: gcc.dg/tree-ssa/slsr-39.c scan-tree-dump-times slsr "Replacing reference: " 4 on Linux/x86_64

On Linux/x86_64, 038b077689bb5310386b04d40a2cea234f01e6aa is the first bad commit commit 038b077689bb5310386b04d40a2cea234f01e6aa Author: Richard Sandiford Date: Wed Jun 22 11:27:15 2022 +0100 data-ref: Improve non-loop disambiguation [PR106019] caused FAIL: gcc.dg/tree-ssa/slsr-39.c

Re: [PATCH] tilegx: Fix infinite loop in gen-mul-tables generator

On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote: Hi, Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get optimized into `j != 922337203685477580', which will result in an infinite loop for certain inputs of `j'. This patch just copies the condition already used by

[PATCH] tilegx: Fix infinite loop in gen-mul-tables generator

Hi, Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get optimized into `j != 922337203685477580', which will result in an infinite loop for certain inputs of `j'. This patch just copies the condition already used by the -DTILEPRO generator code, which doesn't fall into the same

Re: [PATCH] Inline memchr with a small constant string

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 by checking each byte in the constant string. > > > > int f (int

[committed] d: Merge upstream dmd 6203135dc, druntime e150cca1, phobos a4a18d21c.

Hi, This patch merges the D front-end with upstream dmd 6203135dc, and the D run-time library with upstream druntime e150cca1, and phobos a4a18d21c. D front-end changes: - Input parameters can now be applied on extern(C++) functions to bind to `const &' when the `-fpreview=in' flag is

c++: Remove ifdefed code

The only reason I chose to use DECL_UID on this hash table was to make it stable against ASLR and perturbations due to other allocations. It's not required for correctness, as the comment mentions the equality fn uses pointer identity. nathan -- Nathan SidwellFrom

[PATCH v2] c: Extend the -Wpadded message with actual padding size

Hello, I added the ! default_packed directive, and now the test is properly skipped on the targets with that property. I tested with cris-elf target and the test behaves properly. Best regards, Vit Kabele -- >8 -- Subject: [PATCH v2] c: Extend the -Wpadded message with actual padding size When

Re: [PATCH] Inline memchr with a small constant string

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 by checking each byte in the constant string. > > int f (int a) > { >return __builtin_memchr ("eE", a, 2) != 0; > } > > is

[x86 PATCH] PR target/105930: Split *xordi3_doubleword after reload.

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 the x86 are exhausted, the register allocator has to decide

Re: [PATCH] ipa-icf: skip variables with body_removed

> @Honza: PING > > On 5/20/22 09:46, Martin Liška wrote: > > On 5/19/22 17:02, Jan Hubicka wrote: > >>> Similarly to cgraph_nodes, it may happen that body_removed is set > >>> during merging of symbols. > >>> > >>> PR ipa/105600 > >>> > >>> Patch can bootstrap on x86_64-linux-gnu and survives

Re: [PATCH] libstdc++: testsuite: skip fs last_write_time tests if not available

On Wed, 22 Jun 2022 at 07:35, Alexandre Oliva via Libstdc++ wrote: > > > The last_write_time functions are defined in ways that are useful, or > that fail immediately, depending on various macros. When they fail > immediately, the filesystem last_write_time.cc tests fail noisily, but > the fail

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

On Wed, 22 Jun 2022 at 10:25, Jonathan Wakely wrote: > > On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++ > wrote: > > > > > > Several filesystem tests expect to be able to create symlinks even > > when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing > > the amount of

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

On Wed, 22 Jun 2022 at 08:02, Alexandre Oliva via Libstdc++ wrote: > > Hello, Sebastian, > > On Jun 22, 2022, Sebastian Huber wrote: > > > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote: > >> rtems6's rename() implementation errors with EEXIST when the rename-to > >> filename exists,

Re: [PATCH] libstdc++-v3: check for openat

On Wed, 22 Jun 2022 at 07:43, Alexandre Oliva via Libstdc++ wrote: > > > rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares > openat, but there's no openat in libc. Adjust dir-common.h to not > assume ::openat just because of AT_FDCWD. > > Regstrapped on x86_64-linux-gnu (detects

Re: [PATCH] libstdc++: testsuite: skip fs space tests if not available

On Wed, 22 Jun 2022 at 07:28, Alexandre Oliva via Libstdc++ wrote: > > > The do_space function is defined in ways that are useful, or that fail > immediately, depending on various macros. When it fails immediately, > the filesystem space.cc tests fail noisily, but the fail is entirely >

Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

On Wed, 22 Jun 2022 at 07:20, Alexandre Oliva via Libstdc++ wrote: > > > On some target systems (e.g. rtems6.0), removing directory components > while iterating over directory entries may cause some of the directory > entries to be skipped, which prevents the removal of the parent > directory

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++ wrote: > > > Several filesystem tests expect to be able to create symlinks even > when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing > the amount of testing of other filesystem features. > > They are already skipped

Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++ wrote: > > > This patch was originally meant to reduce the likelihood that > nonexistent_path() returns the same pathname for from and to. > > It was prompted by a target system with a non-random implementation of > mkstemp, that returns

Re: [PATCH] libstdc++: testsuite: tolerate non-cancelling sleep

On Wed, 22 Jun 2022 at 06:26, Alexandre Oliva via Libstdc++ wrote: > > > Though sleep, nanosleep and clock_nanosleep are all POSIX cancellation > points, not all target systems follow this POSIX requirement. > 30_threads/thread/native_handle/cancel.cc will run until it times out > on such

Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

On Wed, 22 Jun 2022 at 06:25, Alexandre Oliva via Libstdc++ wrote: > > > Networking functions that net_ts tests rely on are defined in libbsd > on RTEMS, so link with it. > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > aarch64-rtems6. Ok to install? OK, thanks.

Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

On 22/06/2022 08:22, Sebastian Huber wrote: On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote: On rtems under qemu, the frequently-interrupted nanosleep ends up sleeping shorter than expected, by a margin of less than 0,3%. I figured failing the library test over a system (emulator?)

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

On Wed, Jun 22, 2022 at 1:34 AM Vit Kabele wrote: > > Hello, > > On Mon, Jun 20, 2022 at 04:05:17PM -0700, Andrew Pinski wrote: > > > new file mode 100644 > > > index 000..e8f1044a36b > > > --- /dev/null > > > +++ b/gcc/testsuite/c-c++-common/Wpadded.c > > > @@ -0,0 +1,10 @@ > > > +/* {

Re: [PATCH] aarch64: testsuite: symbol-range compile only

Alexandre Oliva writes: > On Jun 21, 2022, Richard Sandiford wrote: > >> Could we instead have a new target selector for whether the memory >> map includes xGB of RAM? > > How about this? Testing on aarch64-rtems6.0. Ok to install? > > > aarch64: testsuite: symbol-range fallback to compile > >

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

Hello, On Mon, Jun 20, 2022 at 04:05:17PM -0700, Andrew Pinski wrote: > > new file mode 100644 > > index 000..e8f1044a36b > > --- /dev/null > > +++ b/gcc/testsuite/c-c++-common/Wpadded.c > > @@ -0,0 +1,10 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-Wpadded" } */ > > + > > +/* >

[PATCH v2, rs6000] Use CC for BCD operations [PR100736]

Hi, This patch uses CC instead of CCFP for all BCD operations. Thus, infinite math flag has no impact on BCD operations. To support BCD overflow and invalid coding, an UNSPEC is defined to move the bit to a general register. The patterns of condition branch and return with overflow bit are

Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

On Tue, Jun 21, 2022 at 11:59:56PM -0400, Jason Merrill wrote: > PR c++/104642 > > gcc/ChangeLog: > > * common.opt: Add -funreachable-traps. > * doc/invoke.texi (-funreachable-traps): Document it. > * opts.cc (finish_options): Enable at -O0 or -Og. > * tree.cc

Re: [PATCH] libgompd: Fix sizes in OMPD support and add local ICVs finctions.

On Wed, Jun 22, 2022 at 04:17:45AM +0200, Mohamed Atef wrote: > I forgot the DCO line. And I edited the commit message, but I can't push, > even forced push doesn't work. No, once you push, it will remain as is. Don't forget next time... Jakub

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

Hello, Sebastian, On Jun 22, 2022, Sebastian Huber wrote: > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote: >> rtems6's rename() implementation errors with EEXIST when the rename-to >> filename exists, even when renaming a file to itself or when renaming >> a nonexisting file. Adjust

[PATCH] libstdc++-v3: check for openat

rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares openat, but there's no openat in libc. Adjust dir-common.h to not assume ::openat just because of AT_FDCWD. Regstrapped on x86_64-linux-gnu (detects and still uses openat), also tested with a cross to aarch64-rtems6 (detects

[PATCH] libstdc++: fs: rtems subdir renaming

RTEMS's implementation of rename(), at least on a temporary RAM filesystem, allows a subdir to be moved into itself, but prevents a dir from being renamed (in?)to an existing directory. Adjust the expectations of filesystem rename tests. Regstrapped on x86_64-linux-gnu, also tested with a

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote: rtems6's rename() implementation errors with EEXIST when the rename-to filename exists, even when renaming a file to itself or when renaming a nonexisting file. Adjust expectations. Regstrapped on x86_64-linux-gnu, also tested with a

[PATCH] libstdc++: testsuite: skip fs last_write_time tests if not available

The last_write_time functions are defined in ways that are useful, or that fail immediately, depending on various macros. When they fail immediately, the filesystem last_write_time.cc tests fail noisily, but the fail is entirely expected. Define HAVE_LWT in the last_write_time.cc tests,

[PATCH] libstdc++: testsuite: skip fs space tests if not available

The do_space function is defined in ways that are useful, or that fail immediately, depending on various macros. When it fails immediately, the filesystem space.cc tests fail noisily, but the fail is entirely expected. Define HAVE_SPACE in the space.cc tests, according to the macros that

[PATCH] libstdc++: testsuite: fs rename to self may fail

rtems6's rename() implementation errors with EEXIST when the rename-to filename exists, even when renaming a file to itself or when renaming a nonexisting file. Adjust expectations. Regstrapped on x86_64-linux-gnu, also tested with a cross to aarch64-rtems6. Ok to install? PS:

Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote: On rtems under qemu, the frequently-interrupted nanosleep ends up sleeping shorter than expected, by a margin of less than 0,3%. I figured failing the library test over a system (emulator?) bug is undesirable, so I put in some

[PATCH] libstdc++: retry removal of dir entries if dir removal fails

On some target systems (e.g. rtems6.0), removing directory components while iterating over directory entries may cause some of the directory entries to be skipped, which prevents the removal of the parent directory from succeeding. Advancing the iterator before removing a member proved not to

Re: [PATCH v5, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, On 21/6/2022 上午 7:08, Segher Boessenkool wrote: > && !flag_trapping_math > > and/or whatever else is needed as well here. > I have a question here. fmin/max are folded to MIN/MAX_EXPR when flag_finite_math_only is set. Seems no-trapping-math is no need to fmin/max? Also xs[min|max]dp do

[PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

Several filesystem tests expect to be able to create symlinks even when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing the amount of testing of other filesystem features. They are already skipped for mingw targets. I've extended the skipping to other targets in which

[PATCH] libstdc++: testsuite: avoid predictable mkstemp

This patch was originally meant to reduce the likelihood that nonexistent_path() returns the same pathname for from and to. 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

[PATCH] libstdc++: async: tolerate slightly shorter sleep

Even without frequent signals interrupting nanosleep, sleep_for on rtems on qemu wakes up too early by a predictable margin of less than 0,3%, which some async tests complain about the too-short wait times. Allow the tests to tolerate a little sleep deprivation. Regstrapped on x86_64-linux-gnu,

[PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

On rtems under qemu, the frequently-interrupted nanosleep ends up sleeping shorter than expected, by a margin of less than 0,3%. I figured failing the library test over a system (emulator?) bug is undesirable, so I put in some tolerance for the drift. Regstrapped on x86_64-linux-gnu, also