[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
--- Comment #13 from Rene Rahn ---
(In reply to Eric Gallager from comment #12)
> (In reply to Rene Rahn from comment #10)
> > I know this is quite old now. But can someone explain me why using `#pragma
> > pack(push, 1)` does work then? I couldn't find enough resources on that. The
> > only thing I found is, that it does literally the same. But wouldn't then
> > the references/pointers still not be valid?
> >
> > So if I change the code to:
> >
> > ```
> > #pragma pack(push, 1)
> > struct Squeeze
> > {
> > short s;
> > };
> > #pragma pack(pop)
> > ```
> >
> > Then it works on godbolt with gcc-trunk.
>
> There are several bugs open about inconsistencies between
> __attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
> 92900, bug 68160, and bug 60972
Ah great. Thanks for pointing to this.
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 --- Comment #7 from Rene Rahn --- Many thanks for your great work!
[Bug c++/94967] New: std::get<0>(tuple const &&) returns wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94967 Bug ID: 94967 Summary: std::get<0>(tuple const &&) returns wrong type Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: --- Hi GCC Team, i couldn't find anything in the advanced search about this but I was wondering if this is not reported already. According to the tuple get implementation, the return type of get over a `const && tuple` should also be `const &&`. But this fails with gcc 7 but works with gcc-8,9 and 10. Here is the link to godbolt: https://godbolt.org/z/akae2V And this is the offending line that fails ``` #include static_assert(std::is_same(std::declval const &&>())), int const &&>::value); ``` Thank you very much for your support.
[Bug c++/94967] std::get<0>(tuple const &&) returns wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94967 --- Comment #2 from Rene Rahn --- Oh, thanks for clarifying this. Best regards
[Bug c++/95910] New: transform view in combination with single view calls const qualified begin even if it is not const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910
Bug ID: 95910
Summary: transform view in combination with single view calls
const qualified begin even if it is not const
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi gcc team,
I am wondering why the following code results in an static assert:
```cpp
#include
#include
#include
auto transform_v = [] (auto && v)
{
static_assert(std::same_as);
return v;
};
using range_t = decltype(std::views::single(0)); // falsely calls const
qualified begin somewhere in stack
// using range_t = std::vector; // OK, everyting as expected.
using transformed_view_t = decltype(std::declval() |
std::views::transform(transform_v));
using ref_t = std::ranges::range_reference_t;
```
Here is the example on https://godbolt.org/z/QWvYue.
It seems, that somewhere in the stack the transform view is promoted to a const
view even though it should not, shouldn't it?
Sorry, if I got something wrong.
[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910 --- Comment #2 from Rene Rahn --- Ok, thanks for the explanation. I do understand the issue now and why it causes the hard error and not an substitution failure. But honestly, given that it works for container because they are wrapped in a ref_view with pointer semantics, makes this very hard to understand. And basically, if you transform something that calls somewhere in the stack a function with auto return type you might not be able to even do `decltype(expression)` to get the return type deduced any more, because the compiler has to instantiate the expression. That makes generic code with auto return types kind of difficult to use, does it? I mean, especially as a library writer I must make sure that the client can use my methods/types in these contexts. And it feels plausible that types are constrained to be mutable somewhere in this context. Is there a general trick to avoid this, except guaranteeing to know the return type before the expression is evaluated? Many thanks for your help!
[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910 --- Comment #4 from Rene Rahn --- > Hmm, if you can't easily specify a concrete return type, then you could maybe > > try constraining the lambda appropriately. In this particular example you > could replace the static_assert with an analogous require-clause, which would > > turn the hard error into a SFINAE-friendly error. Yes, this is basically what I would do know (AFAIK also recommended to always constraint generic types). In this case I could work with an explicit return type, though. Many thanks for your support and time.
[Bug libstdc++/96922] New: primary expression error when using parenthesis around requires expression for some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96922 Bug ID: 96922 Summary: primary expression error when using parenthesis around requires expression for some concepts Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: --- Hi GCC team, I found a strange behavior when using c++17 mode with -fconcepts on gcc 10 as well as gcc 9. Basically, if we use a concept that uses variadic templates then the compiler emits a primary expression error when putting parenthesis around the requires expression. This does not happen if we leave the parenthesis away or if the concept does not use variadic templates. Here the example I ran into (https://godbolt.org/z/95d4Y3): ```cpp #include // Not working for concepts with variadic templates template concept constructible_from = std::is_constructible_v; template requires (constructible_from) // does not work with parenthesis void foo(); template requires constructible_from // works without parenthesis void bar(); // Working without variadic templates template concept constructible_from_one = std::is_constructible_v; template requires (constructible_from_one) void foo(); ``` Thank you very much for your help.
[Bug libstdc++/96922] primary expression error when using parenthesis around requires expression for some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96922 --- Comment #1 from Rene Rahn --- Also note, that this does not happen in c++20 mode using gcc-10.2 (see link to compiler explorer).
[Bug libstdc++/96922] primary expression error when using parenthesis around requires expression for some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96922 Rene Rahn changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #3 from Rene Rahn --- > This is nothing to do with libstdc++, changing component to c++. Sorry, I thought I selected c++. Thank you for correcting this.
[Bug libstdc++/93034] New: variant not constexpr in c++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93034
Bug ID: 93034
Summary: variant not constexpr in c++17 mode
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi there,
I couldn't find a related issue but maybe I just missed it.
But it seems that the copy and move constructor of std::variant are not
declared constexpr for gcc-7.
```
#include
using variant_t = std::variant;
inline constexpr variant_t v1{}; // OK
inline constexpr variant_t v2{v1}; // Error
inline constexpr variant_t v3{std::move(v1)}; // Error
inline constexpr variant_t v4{3}; // OK
```
Here is the corresponding error:
```
:6:33: error: call to non-constexpr function
'std::variant<_Types>::variant(const std::variant<_Types>&) [with _Types =
{int}]'
inline constexpr variant_t v2{v1}; // Error
^
In file included from :1:0:
/opt/compiler-explorer/gcc-7.5.0/include/c++/7.5.0/variant:943:7: note:
'std::variant<_Types>::variant(const std::variant<_Types>&) [with _Types =
{int}]' is not usable as a constexpr function because:
variant(const variant&) = default;
^~~
/opt/compiler-explorer/gcc-7.5.0/include/c++/7.5.0/variant:407:7: note:
defaulted constructor calls non-constexpr
'std::__detail::__variant::_Variant_base<_Types>::_Variant_base(const
std::__detail::__variant::_Variant_base<_Types>&) [with _Types = {int}]'
_Variant_base(const _Variant_base& __rhs)
^
:7:44: error: call to non-constexpr function
'std::variant<_Types>::variant(const std::variant<_Types>&) [with _Types =
{int}]'
inline constexpr variant_t v3{std::move(v1)}; // Error
^
Compiler returned: 1
```
This compiles fine with g++8 and g++9 and trunk.
Compiled on the compiler explorer using g++-7.5 with flags: -std=c++17 -Wall
-Wextra -pedantic
Any help in finding a solution for this would be really appreciated.
[Bug libstdc++/93034] variant not constexpr in c++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93034 --- Comment #2 from rene.r...@fu-berlin.de --- ok, thanks for the heads up. best regards
[Bug c++/93248] New: ICE in decltype of template constructor with default argument within a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248
Bug ID: 93248
Summary: ICE in decltype of template constructor with default
argument within a class template
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi gcc team,
I stumbled over the following weird scenario causing an ICE with gcc>=8.3 but
seems to be fine for the gcc 7 series.
Here is the code in question:
```
#include
template
struct foo
{
template
constexpr foo(t const it,
some_t const index,
size_t const my_index = 0) :
m_it{it},
m_index{index},
m_my_index{my_index}
{}
t m_it{};
size_t m_index{};
size_t m_my_index{};
};
int main()
{
using foo_t = decltype(foo{10, 4u, 2}); // works
// using foo_ice_t = decltype(foo{10, 4u}); // ICE: type deduction in
decltype seems to cause this?
using foo_fine_t = decltype(foo{10, 4u}); // explicit type
declaration works fine.
foo f{10, 3u}; // works fine out of decltype expression.
}
```
The second decltype expression for foo_ice_t causes an ICE for gcc>=8.1 but not
for gcc7.5. If I use the type deduction to create an object of foo everything
works as expected. Can you help me with this?
Many thanks in advance.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
rene.r...@fu-berlin.de changed:
What|Removed |Added
CC||rene.r...@fu-berlin.de
--- Comment #10 from rene.r...@fu-berlin.de ---
I know this is quite old now. But can someone explain me why using `#pragma
pack(push, 1)` does work then? I couldn't find enough resources on that. The
only thing I found is, that it does literally the same. But wouldn't then the
references/pointers still not be valid?
So if I change the code to:
```
#pragma pack(push, 1)
struct Squeeze
{
short s;
};
#pragma pack(pop)
```
Then it works on godbolt with gcc-trunk.
[Bug c++/85513] New: symbol already defined error if using default invocable arguments with lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85513
Bug ID: 85513
Summary: symbol already defined error if using default
invocable arguments with lambda expressions
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Created attachment 44015
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44015&action=edit
The code that produces the aformentioned error.
Hi all, I stumbled over a possible bug in the gcc compiler for the following
code:
```
#include
#include
#include
// DIRTY-FIX: It works, if we use this named lambda to default the callable
argument.
auto dummy = [](char){return true;};
template > // decltype(dummy)
bool bar(f1 && _f1n,
f2 && _f2n = [](char){return false;}) // std::move(dummy)
{
return _f2n('c');
}
int main()
{
auto l1 = [](char v){ return v == 'c';};
auto l2 = [](char v){ return v == 'a';};
std::cout << std::boolalpha << bar(l1) << '\n';
std::cout << std::boolalpha << bar(l2) << '\n';
return 0;
}
```
Expected Output:
false
false
Actual Output:
/tmp/ccNpZtZz.s: Assembler messages:
/tmp/ccNpZtZz.s:317: Error: symbol `_ZNKUlcE0_clEc' is already defined
/tmp/ccNpZtZz.s:588: Error: symbol
`_ZSt4moveIRUlcE0_EONSt16remove_referenceIT_E4typeEOS3_' is already defined
/tmp/ccNpZtZz.s:606: Error: symbol `_ZNSt8functionIFbcEEC2IUlcE0_vvEET_' is
already defined
/tmp/ccNpZtZz.s:922: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E21_M_not_empty_functionIS1_EEbRKT_'
is already defined
/tmp/ccNpZtZz.s:939: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E15_M_init_functorERSt9_Any_dataOS1_'
is already defined
/tmp/ccNpZtZz.s:972: Error: symbol
`_ZNSt17_Function_handlerIFbcEUlcE0_E9_M_invokeERKSt9_Any_dataOc' is already
defined
/tmp/ccNpZtZz.s:1006: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation'
is already defined
/tmp/ccNpZtZz.s:1224: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E15_M_init_functorERSt9_Any_dataOS1_St17integral_constantIbLb1EE'
is already defined
/tmp/ccNpZtZz.s:1252: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E14_M_get_pointerERKSt9_Any_data'
is already defined
/tmp/ccNpZtZz.s:1277: Error: symbol `_ZNSt9_Any_data9_M_accessIPUlcE0_EERT_v'
is already defined
/tmp/ccNpZtZz.s:1297: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E8_M_cloneERSt9_Any_dataRKS3_St17integral_constantIbLb1EE'
is already defined
/tmp/ccNpZtZz.s:1325: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlcE0_E10_M_destroyERSt9_Any_dataSt17integral_constantIbLb1EE'
is already defined
/tmp/ccNpZtZz.s:1406: Error: symbol `_ZNKSt9_Any_data9_M_accessIUlcE0_EERKT_v'
is already defined
/tmp/ccNpZtZz.s:1426: Error: symbol `_ZSt11__addressofIKUlcE0_EPT_RS2_' is
already defined
/tmp/ccNpZtZz.s:1444: Error: symbol `_ZNSt9_Any_data9_M_accessIUlcE0_EERT_v' is
already defined
The following compilers/systems are tested:
g++ (GCC) 7.1.0 // on debian: Linux 3.16.0-4-amd64 #1 SMP Debian
3.16.43-2+deb8u3 (2017-08-15) x86_64 GNU/Linux
g++ (Macports gcc8 8-20170604_1+universal) 8.0.0 20170604 // on mac: Darwin
Kernel Version 16.7.0
Build:
g++-7 -Wall -pedantic -O0 -std=c++17 test.cpp (test.cpp contains the code from
above.)
Note:
The above code will work, if instead of using the anonymous lambda as a default
argument, the named lambda `dummy` would be used. Also, if in the main method
the second call to bar uses again `l1` instead of `l2` the code compiles just
fine. Also clang, does not seem to have any problems with any of the versions,
so this leaves me to the conclusion, that something is wrong with gcc?
Many thanks for your assistance.
Best,
René
[Bug c++/85513] symbol already defined error if using default invocable arguments with lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85513 --- Comment #2 from rene.r...@fu-berlin.de --- Ok, I see. Many thanks for the hint and apologies for the duplicate.
[Bug c++/86282] New: Evaluation order in if constexpr expression seems to be irrelevant for evaluating type traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86282
Bug ID: 86282
Summary: Evaluation order in if constexpr expression seems to
be irrelevant for evaluating type traits
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Created attachment 44309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44309&action=edit
Demo program to show unexpected evaluation of superfluous conditions in
constexpr if
Hi all,
I have an if constexpr expression in the following format:
```
type t{};
if constexpr (my_concept_1 && my_concept_2)
{
// do something.
}
else
{
// do something different.
}
```
Now, I would have assumed, since I am merely evaluating type traits in an
constexpr statement, that if the first condition is false the second condition
will not evaluated by the compiler. But apparently, the second condition seems
to be evaluate nonetheless, which results in superfluous compiler errors, if
for example, `some_fn` does not exists for `t`, but the existence of `some_fn`
would be already checked in `my_concept_t`, such that the first condition must
fail already.
To give you a context, assume your argument can be either a range or a
non-range value. my_concept_1 would check if the range_concept is fulfilled and
in the second condition we check if the value returned by dereferencing
`begin(t)` fulfils my_concept_2, but only if the first condition is `true`.
The compiler would emit an error, that `begin` is not defined if `t` would be
for example an int.
You can find a code example in the attachment.
I compiled it with gcc-8.1 -std=c++17 -fconcepts
I can surly find a way to work around this, but I was in general interested if
this is by design or if there is something unexpected happening.
Thanks for helping me out.
[Bug c++/86282] Evaluation order in if constexpr expression seems to be irrelevant for evaluating type traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86282 --- Comment #2 from rene.r...@fu-berlin.de --- Hi Jonathan, thanks for enlighten me. Before, it wasn't clear to me, that if the nested version works, the conjunction does not necessarily.
[Bug c++/86282] Evaluation order in if constexpr expression seems to be irrelevant for evaluating type traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86282 --- Comment #5 from rene.r...@fu-berlin.de --- Many thanks for the explanation and the code examples.
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 rene.r...@fu-berlin.de changed: What|Removed |Added CC||rene.r...@fu-berlin.de --- Comment #12 from rene.r...@fu-berlin.de --- Hi there, I just wanted to know if there are any news about this issue? Many thanks for your efforts.
[Bug libstdc++/83853] New: conditional_variable induces data_race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83853 Bug ID: 83853 Summary: conditional_variable induces data_race Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: ---
[Bug libstdc++/83853] conditional_variable induces data_race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83853 --- Comment #2 from rene.r...@fu-berlin.de --- Hi, sorry I submitted accidentally before writing the text. I am investigating some use cases for condition_variables using c++11 thread support library. In my use case I have the following setup. 2 Threads are synchronised via a concurrent queue and a condition variable. Thread 2 publishes work in the concurrent queue. Thread 2 is also owner of the condition variable and publishes this to Thread 1 as well. Thread 1, will wait until new work is available using the queue as synchronisation mechanism. If so, it takes the work and if done signals Thread 2 via the condition variable that the work is finished. Thread 2 accesses the wait within a unique lock and uses a shared bool to protect against spurious wake ups. Thread 1 will acquire a lock_guard and update the bool within the lock. After releasing the lock it will call notify_all() (note, it could also be notify_one) to signal that Thread 2 can continue working. The condition variable is in local scope of a while loop in Thread 2. And before leaving the scope it has to wait for the condition variable. So that means these 2 Threads (under the assumption that every thing else does work, which is in this case not trivial) should play ping pong in the sense that: Thread 2 (T2) publishes work in the queue, T1 waits until a new job is available. T1 processes the job and signals T2. T2 is waiting for T1 to finish. T2 goes into another round in the while loop destroying the local condition variable and initialising a new one (possibly in the same memory location) before submitting it to the queue. This goes round and round until all work was processed. But, I experienced on a mac that this setup will cause a dead lock (tried gcc and clang) I did not see this happen on a unix machine. But compiling with -fsantize=thread will also issue a data race warning on unix. Here is the error: WARNING: ThreadSanitizer: data race (pid=18098) Write of size 8 at 0x7ffa298bda68 by thread T2: #0 pthread_cond_destroy ../../.././libsanitizer/tsan/tsan_interceptors.cc:1105 (libtsan.so.0+0x00028fee) #1 Job::~Job() /home/mi/rmaerker/tmp/d0aee45e0ac53d1de5fc5e1836989914/condy.cpp:110 (a.out+0x0040225e) #2 publisher(unsigned int, std::vector >, std::allocator > > >&) /home/mi/rmaerker/tmp/d0aee45e0ac53d1de5fc5e1836989914/condy.cpp:213 (a.out+0x0040225e) #3 void std::__invoke_impl >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&>(std::__invoke_other, void (*&&)(unsigned int, std::vector >, std::allocator > > >&), unsigned int&&, std::vector >, std::allocator > > >&) /import/GCC/7.1.0/include/c++/7.1.0/bits/invoke.h:60 (a.out+0x004035a3) #4 std::__invoke_result >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&>::type std::__invoke >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&>(void (*&&)(unsigned int, std::vector >, std::allocator > > >&), unsigned int&&, std::vector >, std::allocator > > >&) /import/GCC/7.1.0/include/c++/7.1.0/bits/invoke.h:95 (a.out+0x004035a3) #5 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)(), (_S_declval<2ul>)())) std::thread::_Invoker >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>) /import/GCC/7.1.0/include/c++/7.1.0/thread:234 (a.out+0x004035a3) #6 std::thread::_Invoker >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&> >::operator()() /import/GCC/7.1.0/include/c++/7.1.0/thread:243 (a.out+0x004035a3) #7 std::thread::_State_impl >, std::allocator > > >&), unsigned int, std::vector >, std::allocator > > >&> > >::_M_run() /import/GCC/7.1.0/include/c++/7.1.0/thread:186 (a.out+0x004035a3) #8 execute_native_thread_routine ../../../.././libstdc++-v3/src/c++11/thread.cc:83 (libstdc++.so.6+0x000b9bce) Previous read of size 8 at 0x7ffa298bda68 by thread T1: #0 pthread_cond_signal ../../.././libsanitizer/tsan/tsan_interceptors.cc:1091 (libtsan.so.0+0x00028def) #1 __gthread_cond_signal /srv/public/gcc-7.1.0/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:858 (libstdc++.so.6+0x000b3f28) #2 std::condition_variable::notify_one() ../../../.././libstdc++-v3/src/c++11/condition_variable.cc:62 (libstdc++.so.6+0x000b3f28) #3 void std::__invoke_impl(std::__invoke_other, void (*&&)()) /import/GCC/7.1.0/include/c++/7.1.0/bits/invoke.h:60 (a.out+0x00
[Bug libstdc++/83853] conditional_variable induces data_race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83853 --- Comment #4 from rene.r...@fu-berlin.de --- (In reply to Jonathan Wakely from comment #3) > (In reply to rene.rahn from comment #2) > > It basically says, that while T2 is currently destroying the condition > > variable, T1 is still accessing it by calling notify on it??? > > Yes. > > > Note that if the condition variable is put before the while loop and reset > > in every iteration, it performs without warnings on unix, but still dead > > locks on mac. > > If I put the notify of T1 inside of the lock_guard it will also run without > > data race warnings and does not dead lock on mac. > > That seems like the correct fix. The publisher can destroy the condition > variable as soon as Job::wait() returns, which can happen before the > notify_all() call begins. That's a logic error in your program. Calling > notify_all() while the mutex is still locked prevents that. Alright, I am truly sorry. I kind of mist out the last paragraph in the documentation of http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one, which is literally the behaviour I am modelling. So that is definitely a bug in the user code and not in the library. So the same will fix the OSX problem. > > > So there is a little error that might happen in the following situation. > > After T1 updates the shared bool, it leaves the lock. > > So here it could potentially happen, that T1 is preempted and T2 has a > > spurious wakeup but now acquiring the lock, as the predicate returns true > > now. In this case T2 can continue in the loop and destroy the lock, and T1 > > will call notify on it while T2 already destroys it. > > Yes, that is one explanation. Even if it didn't happen often, your code > allows it to happen sometimes, which is a bug. I again would totally agree, and yet > > > Having said that, this seems unlikely to happen so often, does it. I mean I > > am not very confident about how often something like a spurious wake really > > happens, especially as between wait and notify there are only a few cycles. > > It can still happen without a spurious wake up. The call to > pthread_cond_broadcast isn't an atomic operation, it can wake the waiting > thread (which then destroys the pthread_cond_t) and then perform further > reads from the variable before returning. > > > I would really like to know, it is in general forbidden, that the waiting > > thread owns the condition variable as his stack memory might get > > inaccessible when it is put into wait. I couldn't find any information > > regarding this. > > I'm not sure I understand what you're asking, because your code doesn't > destroy the condition variable until after the wait returns. The object > isn't invalidated when "put into wait" only after the wait returns. > > It's not generally forbidden for the waiting thread to own the condition > variable, you just need to ensure no other thread is calling a function on > an object being destroyed (which is generally true for any object, although > std::condition_variable does allow destruction before all waiters have > returned, as long as they've been notified, see > http://en.cppreference.com/w/cpp/thread/condition_variable/ > ~condition_variable -- i.e. std::condition_variable relaxes the usual rules > about accessing an object being destroyed). > > > > Or is there a general user error on my site, which I might not see (because > > it is not a trivial case). I am truly sorry if that would be the case. > > Or is it possible that there is kind of a bug in the condition variable > > implementation, such that the signalling is not broadcasted correctly? > > I think that is very unlikely. Especially if you're seeing the bug on > GNU/Linux and OS X, because they have different implementations of > pthread_cond_t (and libstdc++ just uses that). > > Also you didn't state which standard library you're using with clang, if > it's not libstdc++ then it's even more unlikely that you're seeing the same > bug with two entirely different implementations of std::condition_variable > and pthread_cond_t. > > I don't see any evidence of a bug here. Yes, me neither!!! Sorry, again for bothering, but I am glad for the very competent answers. Helped a lot.
[Bug c++/89953] New: ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Bug ID: 89953 Summary: ICE in nothrow_spec_p, at cp/except.c:1244 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: --- Using gcc-9 20190331_1 experimental on mac osx causes ICE. The respective code works fine with gcc7 and gcc8. I added the preprocessed source in the attachment. Let me know if you need more information or if I need to reduce it to a minimal code example that triggers the ICE. GCC Version: GNU C++17 (MacPorts gcc9 9-20190331_1) version 9.0.1 20190331 (experimental) (x86_64-apple-darwin18) Here the build log: Using built-in specs. COLLECT_GCC=/opt/local/bin/g++-mp-9 Target: x86_64-apple-darwin18 Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9-20190331/configure --prefix=/opt/local --build=x86_64-apple-darwin18 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc9 --includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc9 9-20190331_1' --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk Thread model: posix gcc version 9.0.1 20190331 (experimental) (MacPorts gcc9 9-20190331_1) COLLECT_GCC_OPTIONS='-I' '/Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include' '-I' '/Users/rmaerker/Development/seqan3/seqan3-src/test/include' '-I' '/Users/rmaerker/Development/seqan3/seqan3-src/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include' '-isystem' '/opt/local/include' '-g' '-isysroot' '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' '-Wpedantic' '-Wall' '-Wextra' '-Werror' '-std=c++17' '-fconcepts' '-v' '-save-temps' '-o' 'CMakeFiles/view_get_test.dir/view_get_test.cpp.o' '-c' '-mmacosx-version-min=10.14.0' '-asm_macosx_version_min=10.14' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin18/9.0.1/cc1plus -E -quiet -v -I /Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include -I /Users/rmaerker/Development/seqan3/seqan3-src/test/include -I /Users/rmaerker/Development/seqan3/seqan3-src/include -D__DYNAMIC__ -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include -isystem /opt/local/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk /Users/rmaerker/Development/seqan3/seqan3-src/test/unit/range/view/view_get_test.cpp -fPIC -feliminate-unused-debug-symbols -mmacosx-version-min=10.14.0 -mtune=core2 -std=c++17 -Wpedantic -Wall -Wextra -Werror -fconcepts -g -fworking-directory -fpch-preprocess -o view_get_test.ii ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include" ignoring nonexistent directory "/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.0.1/../../../../../x86_64-apple-darwin18/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks" #include "..." search starts here: #include
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #2 from rene.r...@fu-berlin.de --- Created attachment 46092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46092&action=edit reduced preprocessed source file
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #3 from rene.r...@fu-berlin.de --- Hi sorry, it took me a while to provide the preprocessed source file. I have reduced it with multidelta.
[Bug c++/90003] New: internal compiler error: in tsubst_decl, at cp/pt.c:13783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003 Bug ID: 90003 Summary: internal compiler error: in tsubst_decl, at cp/pt.c:13783 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: --- Created attachment 46096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46096&action=edit preprocessed source file I've got an ICE when compiling with gcc-9 [GNU C++17 (FreeBSD Ports Collection) version 9.0.1 20190303] In the following you see the compiler output. I attached the preprocessed file. Using built-in specs. COLLECT_GCC=/usr/local/bin/g++9 Target: x86_64-portbld-freebsd12.0 Configured with: /wrkdirs/usr/ports/lang/gcc9-devel/work/gcc-9-20190303/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --l$ bdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/l$ b/gcc9/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/loc al --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/gcc9 --build=x86_64-portbld-freebsd12.0 Thread model: posix gcc version 9.0.1 20190303 (experimental) (FreeBSD Ports Collection) COLLECT_GCC_OPTIONS='-D' 'SEQAN3_HAS_BZIP2=1' '-D' 'SEQAN3_HAS_ZLIB=1' '-I' '/home/mi/rmaerker/workspace/build/seqan3-unit/vendor/googletest/googletest/include' '-I' ' /home/mi/rmaerker/workspace/seqan3/test/include' '-I' '/home/mi/rmaerker/workspace/seqan3/include' '-isystem' '/home/mi/rmaerker/workspace/seqan3/submodules/sdsl-lite/ include' '-isystem' '/home/mi/rmaerker/workspace/seqan3/submodules/range-v3/include' '-isystem' '/home/mi/rmaerker/workspace/seqan3/submodules/lemon/include' '-isystem ' '/home/mi/rmaerker/workspace/seqan3/submodules/cereal/include' '-std=c++2a' '-g' '-Wpedantic' '-Wall' '-Wextra' '-save-temps' '-v' '-Werror' '-fconcepts' '-v' '-o' ' CMakeFiles/global_affine_unbanded_test.dir/global_affine_unbanded_test.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd12.0/9.0.1/cc1plus -E -quiet -v -v -I /home/mi/rmaerker/workspace/build/seqan3-unit/vendor/googletest/googletest/inc lude -I /home/mi/rmaerker/workspace/seqan3/test/include -I /home/mi/rmaerker/workspace/seqan3/include -D SEQAN3_HAS_BZIP2=1 -D SEQAN3_HAS_ZLIB=1 -isystem /home/mi/rmae rker/workspace/seqan3/submodules/sdsl-lite/include -isystem /home/mi/rmaerker/workspace/seqan3/submodules/range-v3/include -isystem /home/mi/rmaerker/workspace/seqan3/ submodules/lemon/include -isystem /home/mi/rmaerker/workspace/seqan3/submodules/cereal/include /home/mi/rmaerker/workspace/seqan3/test/unit/alignment/pairwise/global_a ffine_unbanded_test.cpp -mtune=generic -march=x86-64 -std=c++2a -Wpedantic -Wall -Wextra -Werror -fconcepts -g -fworking-directory -fpch-preprocess -o global_affine_un banded_test.ii ignoring nonexistent directory "/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd12.0/9.0.1/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd12.0/9.0.1/../../../../../x86_64-portbld-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /home/mi/rmaerker/workspace/build/seqan3-unit/vendor/googletest/googletest/include /home/mi/rmaerker/workspace/seqan3/test/include /home/mi/rmaerker/workspace/seqan3/include /home/mi/rmaerker/workspace/seqan3/submodules/sdsl-lite/include /home/mi/rmaerker/workspace/seqan3/submodules/range-v3/include /home/mi/rmaerker/workspace/seqan3/submodules/lemon/include /home/mi/rmaerker/workspace/seqan3/submodules/cereal/include [25/1229] /usr/local/lib/gcc9/include/c++/ /usr/local/lib/gcc9/include/c++//x86_64-portbld-freebsd12.0 /usr/local/lib/gcc9/include/c++//backward /usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd12.0/9.0.1/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-D' 'SEQAN3_HAS_BZIP2=1' '-D' 'SEQAN3_HAS_ZLIB=1' '-I' '/home/mi/rmaerker/workspace/build/seqan3-unit/vendor/googletest/googletest/include' '-I' $ /home/mi/rmaerker/workspace/seqa
[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003 --- Comment #2 from rene.r...@fu-berlin.de --- Yes, sorry. this works fine with gcc-7 and gcc-8. I also used multidelta to reduce the preprocessed file.
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #4 from rene.r...@fu-berlin.de --- Hi gcc-team, is there any news about this issue? This ICE currently is always triggered when using the range-v3 library using the 1.0-beta branch with concepts. Let me know, if you need more information. Kind regards
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #6 from rene.r...@fu-berlin.de ---
Here is the code snippet that triggers the ICE:
#include
#include
#include
int main()
{
std::vector v{0, 1, 2, 3, 4};
for (auto e : v | ranges::view::reverse)
{
std::cout << e << '\n';
}
return 0;
}
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #7 from rene.r...@fu-berlin.de --- Created attachment 46177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46177&action=edit preprocessed source file from gcc8 (no ICE) This is the compressed but unreduced preprocessed source file when compiling with gcc 8.3.0.
[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003 --- Comment #4 from rene.r...@fu-berlin.de --- Hi gcc-team, is there any news about this issue? Let me know, if you need more information. Kind regards
[Bug c++/86392] New: templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392
Bug ID: 86392
Summary: templatized friend member function needs declaration
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi, I need some help to understand the following behaviour.
I have a class with a friend get function which implements the
behaviour of std::get. However, the compiler can't find the get function in my
namespace unless I either declare some global function template with the name
get. But it does not even have to match the friend's declaration, as long as
the name is declared once in the namespace or I made with using std::get some
get visible in the context.
Now, I was wondering why for such a template function ADL doesn't work.
Note that it works without out-of-class declaration if the friend template
function uses all it's template parameters as arguments.
So for example:
template
class foo
{
template
friend auto bar(_t && a, foo && b) { ... }
};
would work and the compiler will find bar(3, foo{});
The same behaviour happens with clang, so I think I am just missing something
here and I would appreciate a short explanation.
Sorry for bothering you with probably such simple concerns.
[Bug c++/86392] templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392 --- Comment #1 from rene.r...@fu-berlin.de --- Created attachment 44347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44347&action=edit The example
[Bug c++/86392] templatized friend member function needs declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86392 --- Comment #3 from rene.r...@fu-berlin.de --- Thank you very much for the explanation and sorry for using the wrong platform ;)
