add more C++ name hints
How about adding a few more names from the std namespace to get appropriate hints? This patch compiles and the appropriate messages are printed. Is there a problem with just adding more or even at some point all the symbols of the standard library? gcc/ChangeLog: * cp/name-lookup.cc (get_std_name_hint): Add more symbols from the , , and headers. d-g++-std-io-syms-hints Description: Binary data
Unify container pretty printers [PR65230]
In PR65320 Martin raised the point that the pretty printer for the C++ containers is inconsistent across the different types. It's also inconsistent when it comes to showing different states (empty vs not) of the same type. In addition, IMO some more information should be printed like the template parameters which otherwise certainly can be retrieved through ptype but along with a lot more information one doesn't look for. In the attached patch I've changed the pretty printers of most of the containers to be mostly consistent, at least as far as it is possible given the different nature. I've also fixed some bugs (e.g., printing indeces for set elements). You can see the side-by-side comparison of the output in the text file I attached to the bug (https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419). Bring very long lines or use 'less -S'. Jonathan and I discussed whether such big changes are possible. Someone could consider the output guaranteed by some ABI. We came to the conclusion that this is a bad idea and shouldn't even start to plant that idea in people's minds. The pretty printer output is meant for humans. Comments? d-containers-printers Description: Binary data
Re: [PATCH] i386: Add peephole2 for __atomic_sub_fetch (x, y, z) == 0 [PR98737]
On 1/27/21 11:37 AM, Jakub Jelinek wrote: > Would equality comparison against 0 handle the most common cases. > > The user can write it as > __atomic_sub_fetch (x, y, z) == 0 > or > __atomic_fetch_sub (x, y, z) - y == 0 > thouch, so the expansion code would need to be able to cope with both. Please also keep !=0, <0, <=0, >0, and >=0 in mind. They all can be useful and can be handled with the flags. OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC] Don't move cold code out of loop by checking bb count
On Tue, Aug 10, 2021 at 4:03 AM Xionghu Luo via Gcc-patches
wrote:
> For this case, theorotically I think the master GCC will optimize it to:
>
> invariant;
> for (;;)
> if (unlikely_cond)
> for (;;)
> ;
>
> 'invariant' is moved out of outer loop, but with the patch, it will get:
>
> for (;;)
> if (unlikely_cond)
> {
> invariant;
> for (;;)
>;
> }
>
> 'invariant' is *cold* for outer loop, but it is still *hot* for inner loop,
> so hoist it out of inner loop, this is exactly what we want, right?
Is relying on absolute numbers really what you want? If the
'unlikely_cond' condition depends on the iteration count of the outer
loop the probability of it being true in each individual iteration can
be low (at least that's how I use unlikely) but the overall
probability of needing the code is higher 1 - (1 - p)^n if 'p' is the
probability of 'unlikely_cond' and 'n' is the number of iterations.
Assuming complete independence of the loop iterations, otherwise it's
rather an upper limit.
At the very least I'd generate code like this:
first = true;
for (;;)
if (unlikely_cond)
{
if (first)
{
invariant;
first = false;
}
for (;;)
;
}
If it's worth hoisting the code the the extra test and flag should be
small in cost in comparison.
If 'unlikely_cond' does not in any way depend on the loop iteration
then I think your code generation is fine.
Re: [PATCH] C++ API database
Ping. Anyone having problems with this? And the governance of the file? On Mon, Sep 12, 2022 at 1:51 PM Ulrich Drepper wrote: > After my prior inquiry into the use of python as a build tool for > maintainers didn't produce any negative comments and several active and > even enthusiastic support message I'm going forward with submitting the > patch. > > To repeat the detail, for the generation of the upcoming C++ standard > library module and the hints for missing definitions/declarations in the > std:: namespace we need a list of standard C++ APIs. The information > needed for the two use cases is different but the actual APIs overlap > almost completely and therefore it would be a bad idea to have the data > separated. > > We could opt for a file format that is easy to read in awk and writing the > appropriate scripts to transform the data into the appropriate output > format but this looks ugly, is hard to understand, and a nightmare to > maintain. On the other hand, writing the code in Python is simple and > clean. > > > Therefore, Jonathan and I worked on a CSV file which contains the > necessary information and a Python to create the gperf input file to > generate std-name-hint.h and also, in future, the complete source of the > export interface description for the standard library module. This mode is > not yet used because the module support isn't ready yet. The output file > corresponds to the hand-coded version of the export code Jonathan uses > right now. > > Note that in both of these cases the generated files are static, they > don't depend on the local configuration and therefore are checked into the > source code repository. The script only has to run if the generated files > are explicitly removed or, in maintainer mode, if the CSV file has > changed. For normal compilation from a healthy source code tree the tool > is not needed. > > > One remaining issue is the responsibility for the CSV file. The file > needs to live in the directory of the frontend and therefore nominally > changes need to be approved by the frontend maintainers. The content > entirely consists of information from the standard library, though. Any > change that doesn't break the build on one machine (i.e., the Python script > doesn't fail) will not course any problem because the output format of the > script is correct. Therefore we have been wondering whether the CSV file > should at least have shared ownership between the frontend maintainers and > the libstdc++ maintainers. > > The CSV file contain more hint information than the old hand-coded .gperf > file. So, an additional effect of this patch is the extension of the hints > that are provided but given that the lookup is now fast this shouldn't have > any negative impact. The file is not complete, though, this will come over > time and definitely before the module support is done. > > I build my complete set of compilers with this patch without problems. > > Any comments? > > 2022-09-12 Jonathan Wakely > Ulrich Drepper > > contrib/ChangeLog > * gcc_update: Add rule to generate gcc/cp/std-name-hint.gperf. > > gcc/cp/ChangeLog > * Make-lang.in: Add rule to generate gcc/cp/std-name-hint.gperf. > Adjust rule to generate $(srcdir)/cp/std-name-hint.h. > Add explicit rule to depend cp/name-lookup.o on > $(srcdir)/cp/std-name-hint.h. > * cxxapi-data.csv: New file. Database of C++ APIs. > * gen-cxxapi-file.py: New file. Script to generate source code for > C++ standard library exports and to generate C++ std:: namespace > fix hints. > * std-name-hint.gperf: Regenerated. > * std-name-hint.h: Regenerated. >
Re: [PATCH] C++ API database
On Tue, Oct 18, 2022 at 2:56 AM Jason Merrill wrote: > That makes sense; the file could say something to that effect. I did that. > Or the > CSV file could live in the library directory, or a third directory. The reasoning is that with the file living in the cp subdir we don't have the situation that the compiler sources depend on something that lives elsewhere. Unless I miss something, there are no such outside dependencies and one can build the compiler without the libstdc++ subdir to exist. > And > maybe separate the two generators; it seems like the code shared between them > is pretty small. > The shared code as-is is small, but so is the whole script. Unless someone feels strongly about it I'd prefer not to split the file. It is far easier to forget to make adequate changes in multiple places. There can be changes to the format going forward and even yet another consumer of that information. Keeping more than one (or two, if you count the CSV file) places is sync is asking for trouble. The CSV file could use a header row documenting the fields (as well as > the documentation in the script). > I duplicated the information from the script in the CSV file itself. > > +# This is the file that depends in the generated header file. > > s/in/on/ > Done. There is one additional issue, though, which will likely not hit anyone here but theoretically is handled in the current version of the build infrastructure. The Makefile contains the provision outside of maintainer mode to rebuild the generated files by removing the generated file first. This will require the tools (gperf) to be available but that's deemed OK. With this CSV file as the source of the information we have a two-step derivation of the generated file, though: CSV -> .gperf -> .h The trick used to avoid the rebuild of the .h file today is to not have a prerequisite for the rule. This doesn't work for the two-step process. If the .h and.gperf files are removed there would be no information about the dependency of the .h generation on the .gperf file. This is of course not a new problem in general. GNU make has for a long time support for order-only prerequisites. With those one can exactly express what is needed: ifeq ($(ENABLE_MAINTAINER_RULES), true) FOO.h: FOO.gperf else FOO.h: | FOO.gperf endif gperf ... ifeq ($(ENABLE_MAINTAINER_RULES), true) FOO.gperf: CSV else FOO.gperf: | CSV endif python ... The question here is whether there is a reason not to depend on GNU make features (and whatever other make implemented this extension). The alternative would be to not expose the .gperf file at all, remove it from git and remove it after the .h file was created. This gets us back to a one-step process which the unclean make trick can handle. I haven't found an obvious place where tool dependencies are recorded so I have no idea what the assumptions are. Any comment on this? I have a patch with the order-only rule ready to send out.
Re: add more C++ name hints
Any comment on this? These changes are low-risk so the only real objection I can see is that people don't deem these messages useful in the first place. I would hope, though, that some editors/IDEs provide one-click solutions to add the #includes. On Fri, Aug 5, 2022 at 9:35 PM Ulrich Drepper wrote: > How about adding a few more names from the std namespace to get > appropriate hints? This patch compiles and the appropriate messages are > printed. Is there a problem with just adding more or even at some point > all the symbols of the standard library? > > gcc/ChangeLog: > > * cp/name-lookup.cc (get_std_name_hint): Add more symbols from the > , , and headers. >
[Patch] add more C++ name hints. v2
This is the second version of the proposed patch to add more identifiers to the known list to give hints about #include and version numbers. Marek looked through the first version and found it acceptable but remarked that the list is getting long and the sequential search performed by the current code might not be adequate. Especially because I offered to add even more known names to the list. This second version replaces the current lookup implementation with a gperf-generated hash function. Since gperf is already a dependency for maintainers the use of the tool itself shouldn't be a problem. I followed the existing practice for the cfns.gperf file and its use so, if the handling of that file works, so should the handling of the new file, std-name-hint.gperf. Please let me know if this is acceptable. I built a compiler with this code and tested the hinting. contrib/ChangeLog * gcc_update (files_and_dependencies): Add gcc/cp/std-name-hint.h depend on gcc/cp/std-name-hint.gperf. gcc/cp/ChangeLog * Make-lang.in: Add rule to build std-name-hint.h. * name-lookup.cc (struct std_name_hint): Remove definition. Instead... Include "std-name-hint.h". (get_std_name_hint): Remove hints array and lookup code. Instead call std_name_hint_lookup::find. * std-name-hint.gperf: New file. * std-name-hint.h: New file. d-g++-std-io-syms-hints-v2 Description: Binary data
Re: [Patch] add more C++ name hints. v2
Ping! Anyone interested in this. I'm bootstrapping my trunk builds with this patch without problems. On Mon, Aug 22, 2022 at 9:09 PM Ulrich Drepper wrote: > This is the second version of the proposed patch to add more identifiers > to the known list to give hints about #include and version numbers. > > Marek looked through the first version and found it acceptable but > remarked that the list is getting long and the sequential search performed > by the current code might not be adequate. Especially because I offered to > add even more known names to the list. > > This second version replaces the current lookup implementation with a > gperf-generated hash function. Since gperf is already a dependency for > maintainers the use of the tool itself shouldn't be a problem. > > I followed the existing practice for the cfns.gperf file and its use so, > if the handling of that file works, so should the handling of the new file, > std-name-hint.gperf. > > Please let me know if this is acceptable. I built a compiler with this > code and tested the hinting. > > contrib/ChangeLog > * gcc_update (files_and_dependencies): Add gcc/cp/std-name-hint.h > depend on gcc/cp/std-name-hint.gperf. > > gcc/cp/ChangeLog > * Make-lang.in: Add rule to build std-name-hint.h. > * name-lookup.cc (struct std_name_hint): Remove definition. > Instead... > Include "std-name-hint.h". > (get_std_name_hint): Remove hints array and lookup code. Instead > call > std_name_hint_lookup::find. > * std-name-hint.gperf: New file. > * std-name-hint.h: New file. >
OpenMP 5.1: omp_display_env
I know OpenMP 5.1 is not really a focus yet but adding this new interface
should not be problematic. I stumbled across this part of the spec and the
functionality is really already mostly there in the form of
OMP_DISPLAY_ENV=verbose etc. This is just a function interface to the same
functionality.
Aside from the busywork to add a new interface (headers, map file) the only
real question was how to deal with the two parameters which are passed
to handle_omp_display_env in the current implementation. The
omp_display_env interface is supposed to show the information of the
initial values and therefore I think the right implementation is to store
the values determined in the constructor in two global, static variables
and reuse them.
The rest should be completely boring and therefore not distracting anyone
from OpenMP 5.0 work.
OK to commit?
diff --git a/libgomp/env.c b/libgomp/env.c
index a24deabcd58..84038eb4683 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -99,6 +99,9 @@ int goacc_default_dims[GOMP_DIM_MAX];
#ifndef LIBGOMP_OFFLOADED_ONLY
+static int wait_policy;
+static unsigned long stacksize = GOMP_DEFAULT_STACKSIZE;
+
/* Parse the OMP_SCHEDULE environment variable. */
static void
@@ -1210,46 +1213,11 @@ parse_gomp_openacc_dim (void)
}
}
-static void
-handle_omp_display_env (unsigned long stacksize, int wait_policy)
+void
+omp_display_env (int verbose)
{
- const char *env;
- bool display = false;
- bool verbose = false;
int i;
- env = getenv ("OMP_DISPLAY_ENV");
- if (env == NULL)
-return;
-
- while (isspace ((unsigned char) *env))
-++env;
- if (strncasecmp (env, "true", 4) == 0)
-{
- display = true;
- env += 4;
-}
- else if (strncasecmp (env, "false", 5) == 0)
-{
- display = false;
- env += 5;
-}
- else if (strncasecmp (env, "verbose", 7) == 0)
-{
- display = true;
- verbose = true;
- env += 7;
-}
- else
-env = "X";
- while (isspace ((unsigned char) *env))
-++env;
- if (*env != '\0')
-gomp_error ("Invalid value for environment variable OMP_DISPLAY_ENV");
-
- if (!display)
-return;
-
fputs ("\nOPENMP DISPLAY ENVIRONMENT BEGIN\n", stderr);
fputs (" _OPENMP = '201511'\n", stderr);
@@ -1409,13 +1377,52 @@ handle_omp_display_env (unsigned long stacksize,
int wait_policy)
fputs ("OPENMP DISPLAY ENVIRONMENT END\n", stderr);
}
+static void
+handle_omp_display_env (void)
+{
+ const char *env;
+ bool display = false;
+ bool verbose = false;
+
+ env = getenv ("OMP_DISPLAY_ENV");
+ if (env == NULL)
+return;
+
+ while (isspace ((unsigned char) *env))
+++env;
+ if (strncasecmp (env, "true", 4) == 0)
+{
+ display = true;
+ env += 4;
+}
+ else if (strncasecmp (env, "false", 5) == 0)
+{
+ display = false;
+ env += 5;
+}
+ else if (strncasecmp (env, "verbose", 7) == 0)
+{
+ display = true;
+ verbose = true;
+ env += 7;
+}
+ else
+env = "X";
+ while (isspace ((unsigned char) *env))
+++env;
+ if (*env != '\0')
+gomp_error ("Invalid value for environment variable OMP_DISPLAY_ENV");
+
+ if (display)
+omp_display_env (verbose);
+}
+
static void __attribute__((constructor))
initialize_env (void)
{
- unsigned long thread_limit_var, stacksize = GOMP_DEFAULT_STACKSIZE;
+ unsigned long thread_limit_var;
unsigned long max_active_levels_var;
- int wait_policy;
/* Do a compile time check that mkomp_h.pl did good job. */
omp_check_defines ();
@@ -1546,7 +1553,7 @@ initialize_env (void)
gomp_error ("Stack size change failed: %s", strerror (err));
}
- handle_omp_display_env (stacksize, wait_policy);
+ handle_omp_display_env ();
/* OpenACC. */
diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index 4ec39c4e61b..2f36e326624 100644
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
@@ -736,3 +736,9 @@ omp_get_default_allocator_ ()
{
return (intptr_t) omp_get_default_allocator ();
}
+
+void
+omp_display_env_ (const int32_t *verbose)
+{
+ omp_display_env (*verbose);
+}
diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index 8ea27b5565f..fe51d3dbd46 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -199,6 +199,12 @@ OMP_5.0.1 {
omp_fulfill_event_;
} OMP_5.0;
+OMP_5.1 {
+ global:
+ omp_display_env;
+ omp_display_env_;
+} OMP_5.0.1;
+
GOMP_1.0 {
global:
GOMP_atomic_end;
diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in
index 69f96f09124..c93db968d2e 100644
--- a/libgomp/omp.h.in
+++ b/libgomp/omp.h.in
@@ -293,6 +293,8 @@ extern void omp_free (void *,
omp_allocator_handle_t __GOMP_DEFAULT_NULL_ALLOCATOR)
__GOMP_NOTHROW;
+extern void omp_display_env (int) __GOMP_NOTHROW;
+
#ifdef __cplusplus
}
#endif
diff --git a/libgomp/omp_lib.f90.in b/libgomp/omp_lib.f90.in
index 851f85f5316..4939bfd9751 100644
--- a/libgomp/omp_lib.f90.in
+++ b/libgomp/omp_lib.f90.in
@@ -653,6 +653,12 @@
end function
end interface
+interface
Re: OpenMP 5.1: omp_display_env
Hi,
On Fri, Jul 30, 2021 at 9:50 AM Tobias Burnus
wrote:
> this patch breaks offloading. The reason is that most code
> in env.c is enclosed in:
>
Indeed, normally I test that configuration but my setup currently has a few
problems.
Although the env vars aren't parsed for those targets it seems to be
appropriate to still provide the complete implementation. There are other
functions which print something this is likely bogus as well and/or the
output isn't seen.
How about this change? Compiles for me for NVPTX. It doesn't change
anything but the location of the function definition in the file and
includes for LIBGOMP_OFFLOADED_ONLY some headers which aren't included in
this file before (but are present).
diff --git a/libgomp/env.c b/libgomp/env.c
index 5220877d533..e7ef294139d 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -30,15 +30,16 @@
#include "libgomp.h"
#include "gomp-constants.h"
#include
+#include
+#include "thread-stacksize.h"
+#ifdef HAVE_INTTYPES_H
+# include /* For PRIu64. */
+#endif
#ifndef LIBGOMP_OFFLOADED_ONLY
#include "libgomp_f.h"
#include "oacc-int.h"
#include
#include
-#include
-#ifdef HAVE_INTTYPES_H
-# include /* For PRIu64. */
-#endif
#ifdef STRING_WITH_STRINGS
# include
# include
@@ -52,7 +53,6 @@
# endif
#endif
#include
-#include "thread-stacksize.h"
#ifndef HAVE_STRTOULL
# define strtoull(ptr, eptr, base) strtoul (ptr, eptr, base)
@@ -97,11 +97,178 @@ char *goacc_device_type;
int goacc_device_num;
int goacc_default_dims[GOMP_DIM_MAX];
-#ifndef LIBGOMP_OFFLOADED_ONLY
-
static int wait_policy;
static unsigned long stacksize = GOMP_DEFAULT_STACKSIZE;
+
+void
+omp_display_env (int verbose)
+{
+ int i;
+
+ fputs ("\nOPENMP DISPLAY ENVIRONMENT BEGIN\n", stderr);
+
+ fputs (" _OPENMP = '201511'\n", stderr);
+ fprintf (stderr, " OMP_DYNAMIC = '%s'\n",
+ gomp_global_icv.dyn_var ? "TRUE" : "FALSE");
+ fprintf (stderr, " OMP_NESTED = '%s'\n",
+ gomp_global_icv.max_active_levels_var > 1 ? "TRUE" : "FALSE");
+
+ fprintf (stderr, " OMP_NUM_THREADS = '%lu",
gomp_global_icv.nthreads_var);
+ for (i = 1; i < gomp_nthreads_var_list_len; i++)
+fprintf (stderr, ",%lu", gomp_nthreads_var_list[i]);
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_SCHEDULE = '");
+ if ((gomp_global_icv.run_sched_var & GFS_MONOTONIC))
+{
+ if (gomp_global_icv.run_sched_var != (GFS_MONOTONIC | GFS_STATIC))
+ fputs ("MONOTONIC:", stderr);
+}
+ else if (gomp_global_icv.run_sched_var == GFS_STATIC)
+fputs ("NONMONOTONIC:", stderr);
+ switch (gomp_global_icv.run_sched_var & ~GFS_MONOTONIC)
+{
+case GFS_RUNTIME:
+ fputs ("RUNTIME", stderr);
+ if (gomp_global_icv.run_sched_chunk_size != 1)
+ fprintf (stderr, ",%d", gomp_global_icv.run_sched_chunk_size);
+ break;
+case GFS_STATIC:
+ fputs ("STATIC", stderr);
+ if (gomp_global_icv.run_sched_chunk_size != 0)
+ fprintf (stderr, ",%d", gomp_global_icv.run_sched_chunk_size);
+ break;
+case GFS_DYNAMIC:
+ fputs ("DYNAMIC", stderr);
+ if (gomp_global_icv.run_sched_chunk_size != 1)
+ fprintf (stderr, ",%d", gomp_global_icv.run_sched_chunk_size);
+ break;
+case GFS_GUIDED:
+ fputs ("GUIDED", stderr);
+ if (gomp_global_icv.run_sched_chunk_size != 1)
+ fprintf (stderr, ",%d", gomp_global_icv.run_sched_chunk_size);
+ break;
+case GFS_AUTO:
+ fputs ("AUTO", stderr);
+ break;
+}
+ fputs ("'\n", stderr);
+
+ fputs (" OMP_PROC_BIND = '", stderr);
+ switch (gomp_global_icv.bind_var)
+{
+case omp_proc_bind_false:
+ fputs ("FALSE", stderr);
+ break;
+case omp_proc_bind_true:
+ fputs ("TRUE", stderr);
+ break;
+case omp_proc_bind_master:
+ fputs ("MASTER", stderr);
+ break;
+case omp_proc_bind_close:
+ fputs ("CLOSE", stderr);
+ break;
+case omp_proc_bind_spread:
+ fputs ("SPREAD", stderr);
+ break;
+}
+ for (i = 1; i < gomp_bind_var_list_len; i++)
+switch (gomp_bind_var_list[i])
+ {
+ case omp_proc_bind_master:
+ fputs (",MASTER", stderr);
+ break;
+ case omp_proc_bind_close:
+ fputs (",CLOSE", stderr);
+ break;
+ case omp_proc_bind_spread:
+ fputs (",SPREAD", stderr);
+ break;
+ }
+ fputs ("'\n", stderr);
+ fputs (" OMP_PLACES = '", stderr);
+ for (i = 0; i < gomp_places_list_len; i++)
+{
+ fputs ("{", stderr);
+ gomp_affinity_print_place (gomp_places_list[i]);
+ fputs (i + 1 == gomp_places_list_len ? "}" : "},", stderr);
+}
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_STACKSIZE = '%lu'\n", stacksize);
+
+ /* GOMP's default value is actually neither active nor passive. */
+ fprintf (stderr, " OMP_WAIT_POLICY = '%s'\n",
+ wait_policy > 0 ? "ACTIVE" : "PASSIVE");
+ fprintf (stderr, " OMP_THREAD_LIMIT = '%u'\n",
+ gomp_global_icv.thread_limit_var);
+ fprintf (stderr, " OMP_MAX_ACTIVE_LEVELS = '%u'\n",
+ gomp_global_icv.max_active_levels_var);
+
+ fpri
Re: OpenMP 5.1: omp_display_env
On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
> I think for now it would be better to guard the omp_display_env_*
> in fortran.c with #ifndef LIBGOMP_OFFLOADED_ONLY
>
OK, easy enough. This compiles for me.
diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index 76285d4376b..26ec8ce30d8 100644
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
@@ -738,6 +738,7 @@ omp_get_default_allocator_ ()
return (intptr_t) omp_get_default_allocator ();
}
+#ifndef LIBGOMP_OFFLOADED_ONLY
void
omp_display_env_ (const int32_t *verbose)
{
@@ -749,3 +750,4 @@ omp_display_env_8_ (const int64_t *verbose)
{
omp_display_env (!!*verbose);
}
+#endif /* LIBGOMP_OFFLOADED_ONLY */
std::atomic_flag::test
This is not yet implemented. Here is a patch.
2020-05-08 Ulrich Drepper
* include/bits/atomic_base.h (atomic_flag): Implement test
memeber function.
* include/std/version: Define __cpp_lib_atomic_flag_test.
* testsuite/29_atomics/atomic_flag/test/explicit.cc: New file.
* testsuite/29_atomics/atomic_flag/test/implicit.cc: New file.
libatomic does not have a function 'test' so I implemented it with
__atomic_load (which takes care of memory ordering) and then compare
with the set-value.
The code generated at least for x86-64 looks good, it's a
straight-forward load, nothing else.
2020-05-08 Ulrich Drepper
* include/bits/atomic_base.h (atomic_flag): Implement test memeber
function.
* include/std/version: Define __cpp_lib_atomic_flag_test.
* testsuite/29_atomics/atomic_flag/test/explicit.cc: New file.
* testsuite/29_atomics/atomic_flag/test/implicit.cc: New file.
diff --git libstdc++-v3/include/bits/atomic_base.h
libstdc++-v3/include/bits/atomic_base.h
index 87fe0bd6000..3b66b040976 100644
--- libstdc++-v3/include/bits/atomic_base.h
+++ libstdc++-v3/include/bits/atomic_base.h
@@ -208,6 +208,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __atomic_test_and_set (&_M_i, int(__m));
}
+#if __cplusplus > 201703L
+#define __cpp_lib_atomic_flag_test 201907L
+
+_GLIBCXX_ALWAYS_INLINE bool
+test(memory_order __m = memory_order_seq_cst) noexcept
+{
+ __atomic_flag_data_type __v;
+ __atomic_load(&_M_i, &__v, int(__m));
+ return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
+}
+
+_GLIBCXX_ALWAYS_INLINE bool
+test(memory_order __m = memory_order_seq_cst) volatile noexcept
+{
+ __atomic_flag_data_type __v;
+ __atomic_load(&_M_i, &__v, int(__m));
+ return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
+}
+#endif // C++20
+
_GLIBCXX_ALWAYS_INLINE void
clear(memory_order __m = memory_order_seq_cst) noexcept
{
diff --git libstdc++-v3/include/std/version libstdc++-v3/include/std/version
index c3a5bd26e63..c6bde2cfbda 100644
--- libstdc++-v3/include/std/version
+++ libstdc++-v3/include/std/version
@@ -164,6 +164,7 @@
#if __cplusplus > 201703L
// c++2a
+#define __cpp_lib_atomic_flag_test 201907L
#define __cpp_lib_atomic_float 201711L
#define __cpp_lib_atomic_ref 201806L
#define __cpp_lib_atomic_value_initialization 201911L
--- /dev/null 2020-05-07 16:14:59.793169510 +0200
+++ libstdc++-v3/testsuite/29_atomics/atomic_flag/test/explicit.cc
2020-05-08 12:53:14.134152671 +0200
@@ -0,0 +1,32 @@
+// { dg-do run { target c++2a } }
+// { dg-require-thread-fence "" }
+
+// Copyright (C) 2008-2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
