[Bug c++/98859] pedantic error on use of __VA_OPT__ before C++20 is unnecessary and counterproductive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98859 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #2 from Yongwei Wu --- Here is anotehr good reason: https://stackoverflow.com/questions/48045470/portably-detect-va-opt-support/48045656 People can detect the presence of __VA_OPT__ support. Currently, the detection code would cause warnings when -std is set to something like "c++17" (though luckily not "gnu++17").
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #29 from Yongwei Wu --- As usual, test results are always elusive. I have to add yet another important piece of information. The very bad performance result does not occur on Linux, but only on macOS (Homebrew versions of GCC and libatomic). So far, it seems to indicate that this is more a libatomic issue on macOS, which I traced to pthread_mutex_lock, instead of "lock cmpxchg16b" on Linux...
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #28 from Yongwei Wu --- OK, somewhat answering myself. I was not aware of the fact that 128-bit atomic read has to be implemented using cmpxchg16b as well, thus defeating some non-CAS usage scenarios. The natural question is: which usage scenario is more significant? Or is there a way to support both? I still think lock-free data structures are too import to ignore.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #27 from Yongwei Wu --- Anyone can show a valid use case for a non-lock-free version of 128-bit atomic_compare_exchange? I am trying to use it in a data structure intended to be lock-free. I am surprised to find that the C++ std::atomic::compare_exchange_weak does not result in lock-free code for a 128-bit struct intended for ABA-free CAS. As a result, the GCC-generated code is MUCH slower than the mutex-based version in my 8-thread contention test, defeating all its valid purposes. I am talking about a 10x difference. And the Clang-generated code is more than 200x faster in the same test. Friends, being 200x worse in an important use case (lock-free, ABA-free data structures like queues and lists) is not funny at all.
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #3 from Yongwei Wu --- Is there really a valid use case for a non-lock-free version of 128-bit CAS? I am using it in a lock-free data structure. The GCC-generated code is MUCH slower than the mutex-based version, defeating all its valid purposes. I am talking about a 10x difference. And the Clang-generated code is more than 200x faster in my 8-thread contention test. To me, the current GCC behaviour is not missed optimization. It is pessimization. I am really having a difficult time understanding the rationale of the current design.
[Bug c++/98283] New: decltype(auto) may be deduce static data member to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98283
Bug ID: 98283
Summary: decltype(auto) may be deduce static data member to
wrong type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wuyongwei at gmail dot com
Target Milestone: ---
The following code shows that `decltype(auto)` is deduced to the wrong type
when used in template code for an expression like `(var.static_data_member>)`.
```cpp
#include
#include
#include
template
struct type_displayer;
#define TYPE_DISPLAY(x) type_displayer test_obj;
struct SkipField {};
struct TestSkip {
template struct FIELD;
int value;
static SkipField unused;
template
struct FIELD {
T &
FIELD(T &) : obj(std::forward(ref))
{
}
decltype(auto) value()
{
return (obj.value);
}
static constexpr const char *name()
{
return "value";
}
};
template
struct FIELD {
T &
FIELD(T &) : obj(std::forward(ref))
{
}
decltype(auto) value()
{
return (obj.unused);
}
decltype((obj.unused)) valueAlt()
{
return (obj.unused);
}
static constexpr const char *name()
{
return "unused";
}
};
};
int main()
{
TestSkip s;
// decltype((TestSkip::FIELD(s).value()))is int&
// decltype((TestSkip::FIELD(s).value()))is SkipField,
but it should be SkipField&
// decltype((TestSkip::FIELD(s).valueAlt())) is SkipField&
}
```
This is a simplified usage scenario, where I want to use a macro to generate
code to emulate static reflection. Here is the problematic part:
```cpp
decltype(auto) value()
{
return (obj.unused);
}
```
This function returns `SkipField`, instead of the expected `SkipField&`. I have
verified that clang does what I want.
Currently I have to avoid `decltype(auto)` as a workaround:
```cpp
decltype((obj.unused)) valueAlt()
{
return (obj.unused);
}
```
(I used the macro TYPE_DISPLAY to check the type of an expression.)
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #30 from Yongwei Wu --- I encountered this problem too. I'd say I would prefer (void)some_system_function_that_warns(...); to int ignored __attribute__((unused)); ignored = some_system_function_that_warns(...); The latter is not only verbose, but also creating portability issues. Should I also define macros for compilers that do not support __attribute__? It is extremely messy!
[Bug c++/69260] New: C++14 template instantiation problem in GCC (up to 5.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69260 Bug ID: 69260 Summary: C++14 template instantiation problem in GCC (up to 5.3) Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wuyongwei at gmail dot com Target Milestone: --- Created attachment 37328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37328=edit Test code to show the problem. The attached C++14 template code does not work in GCC 4.9 to 5.3, unless one uncomments the first line in main to have an explicit instantiation. The explicit instantiation is not needed in Clang. I cannot find any reason why an explicit instantiation is needed. The error message in GCC 5.3 is: test.cpp: In function 'int main()': test.cpp:19:43: error: conversion from '' to non-scalar type 'std::function<int(int, int, int)>' requested std::function<int(int, int, int)> f = sum<int, int, int>; ^
[Bug c++/69222] New: C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69222 Bug ID: 69222 Summary: C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3 Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wuyongwei at gmail dot com Target Milestone: --- Created attachment 37299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37299=edit Test C++ file I have an implementation of Y Combinator in C++, which works in GCC 4.9 to 5.1 as well as Clang 3.5 (in C++14 mode). It stops working in GCC 5.2 and 5.3, so I think it is regression. I think GCC is being too eager in template instantiation. As I also tried using the GCC 5.1 C++ header files with GCC 5.2 and got the same errors, I guess it is a C++ front end problem. The test program is supposed to apply the Y combinator to a non-recursive function almost_fac to get a factorial function. It should compile well and output two lines of "120", but now it fails the compilation at the "fix_curry(almost_fac)" line. I tested on Windows and OS X. The Windows error output is: In file included from test_gcc.cpp:1:0: C:/mingw64/x86_64-w64-mingw32/include/c++/functional: In substitution of 'template std::function<_Res(_ArgTypes ...)>::function(_Functor) [with _Functor = std::function<std::function<int(int)>(self_ref_func<std::function<int(int)> >)>; = ]': C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:45: recursively required by substitution of 'template std::function<_Res(_ArgTypes ...)>::function(_Functor) [with _Functor = std::function<std::function<int(int)>(self_ref_func<std::function<int(int)> >)>; = ]' C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:45: required by substitution of 'template std::function<_Res(_ArgTypes ...)>::function(_Functor) [with _Functor = std::function<std::function<int(int)>(self_ref_func<std::function<int(int)> >)>; = ]' test_gcc.cpp:47:51: required from 'fix_curry(std::function<std::function<_Rs(_Tp)>(std::function<_Rs(_Tp)>)>)::<lambda(fn_self_ref)>::<lambda(_Tp&&)> [with _Rs = int; _Tp = int]' test_gcc.cpp:45:34: required from 'struct fix_curry(std::function<std::function<_Rs(_Tp)>(std::function<_Rs(_Tp)>)>)::<lambda(fn_self_ref)> [with _Rs = int; _Tp = int; fn_self_ref = self_ref_func<std::function<int(int)> >]::<lambda(int&&)>' test_gcc.cpp:45:21: required from 'fix_curry(std::function<std::function<_Rs(_Tp)>(std::function<_Rs(_Tp)>)>)::<lambda(fn_self_ref)> [with _Rs = int; _Tp = int; fn_self_ref = self_ref_func<std::function<int(int)> >]' test_gcc.cpp:43:10: required from 'struct fix_curry(std::function<std::function<_Rs(_Tp)>(std::function<_Rs(_Tp)>)>) [with _Rs = int; _Tp = int]::<lambda(fn_self_ref)>' test_gcc.cpp:50:5: required from 'std::function<_Rs(_Tp)> fix_curry(std::function<std::function<_Rs(_Tp)>(std::function<_Rs(_Tp)>)>) [with _Rs = int; _Tp = int]' test_gcc.cpp:69:43: required from here C:/mingw64/x86_64-w64-mingw32/include/c++/functional:1981:69: fatal error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) using _Invoke = decltype(__callable_functor(std::declval<_Functor&>()) ^ compilation terminated.
