https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96922
Rene Rahn changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #3 from Rene Rahn
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).
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
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94967
--- Comment #2 from Rene Rahn ---
Oh, thanks for clarifying this.
Best regards
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 implementati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248
--- Comment #7 from Rene Rahn ---
Many thanks for your great work!
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
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
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
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
++
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
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
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
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=edit
preprocessed source file from gcc8 (no ICE)
This is the compressed but unreduced preprocessed source f
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
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
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.
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=edit
preprocessed source file
I've got an ICE when compil
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.
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=edit
reduced preprocessed source file
++
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
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
;)
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=edit
The example
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
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.
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.
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=edit
Demo program to s
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.
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=edit
The code that produ
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
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
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
35 matches
Mail list logo
