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 (ge
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 templat
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.
Plea
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
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 suppor
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 s
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
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
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 num
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
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 seem
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..26ec8ce30
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.
13 matches
Mail list logo
