https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110765
--- Comment #2 from Hannes Hauswedell ---
Thanks for the quick reply. I agree it is the same problem.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 55595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55595&action=edit
GCC12's intermediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425
--- Comment #2 from Hannes Hauswedell ---
Thanks for the quick reply, and nice that it is already fixed for 13!
I assume this will not be backported? It wouldn't be a huge problem, because it
is possible to workaround with non-friend operators.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following snippet is rejected by GCC10, GCC11 and GCC12:
```cpp
#include
template
concept weakly_eq_comparable = requires (T1 t1, T2 t2) { { t1 == t2 } ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107471
--- Comment #2 from Hannes Hauswedell ---
Great, thanks!
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
In bits/stl_iterator.h:
```cpp
/// An iterator/sentinel adaptor for representing a non-common range.
template _Sent>
requires (!same_as<_It, _Sent>) &a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
#include
template
requires std::unsigned_integral
struct S
{
template // template
friend class S;
};
int main
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I stumbled over the following:
```cpp
#define OPTION 0 // or 1-4
template
struct Base
{
Base() = default;
Base(Base const &) = default;
Base(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669
Hannes Hauswedell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669
--- Comment #1 from Hannes Hauswedell ---
This affects GCC 10.4 and GCC 11.3 since move-only views were backported.
The following part of the draft standard also needs changing:
https://eel.is/c++draft/range.all#general-2.1
--->
decay-copy(E
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
In GCC12.1 we now have ranges that are views, but whose references aren't
viewable. See the code below.
Be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320
--- Comment #8 from Hannes Hauswedell ---
Thanks a lot for fixing this in a way that preserves the backport <3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369
--- Comment #5 from Hannes Hauswedell ---
I have found a workaround for my code:
template
-class aminoacid_base : public alphabet_base, public
aminoacid_empty_base
+class aminoacid_base : public aminoacid_empty_base, public
alphabet_base
This
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 53322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53322&action=edit
backtrace
Also reproducible with G
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following snippet builds on GCC10.3, GCC11.3, GCC12.1 and even MSVC 19.32.
It no longer builds on GCC10.4. This might be related to
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 53259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53259&action=edit
backtrace
ICE when using generated com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803
--- Comment #8 from Hannes Hauswedell ---
OK, thank you anyway!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803
--- Comment #6 from Hannes Hauswedell ---
Since it seems like 10.4 is around the corner... any chance this will make it?
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #19 from Hannes Hauswedell ---
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #11 from Hannes Hauswedell ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Hannes Hauswedell from comment #8)
> > Hi, I wanted to ask politely whether you have discussed this issue and came
> > to a conclusion?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #8 from Hannes Hauswedell ---
Hi, I wanted to ask politely whether you have discussed this issue and came to
a conclusion?
It if it is still being discussed, can you at least "confirm" this issue and
put it on some list for the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #6 from Hannes Hauswedell ---
Yes, I understand that, and I know that it is your role to uphold these rules
(which I believe make a lot of sense in general) and that you have other
interests to consider beyond mine :)
I would still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #4 from Hannes Hauswedell ---
Well... we also try to avoid breaking changes in the standard ^^
The thing is that code that relies on the old definition will break one way or
another (and independent of compiler flags). The longer GC
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Views are no longer required to be default-initializable [P2325R3]. This has
apparently been fixed on current trunk, but GCC11.2 and GCC10.3 still fail at
this example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803
--- Comment #5 from Hannes Hauswedell ---
Thanks a lot for the fix! Any chance this will make into the 10.x branch?
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
See the code below. Two initializing statements fail to build, although they
shouldn't influence CTAD of the outer type at all (IMHO).
struct Inner
{
int i = 0;
};
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696
--- Comment #2 from Hannes Hauswedell ---
What do you mean with "It doesn't work this way"?
Maybe I wasn't clear in my original post; I am not interested in a dispatching
mechanism for the application, I just want to have an mini-application th
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I really like the new feature levels, so I have created the respective binaries
for an application. I now want to dispatch to the correct one, so I thought the
easiest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778
--- Comment #6 from Hannes Hauswedell ---
Ok, the ICE on Linux is a different one. This particular ICE happens only on
FreeBSD. I have rebuilt GCC9 from source with fullbootstrap and without any
-march settings. The problem remains.
What can I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778
Hannes Hauswedell changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778
--- Comment #4 from Hannes Hauswedell ---
Thanks for the quick reply, Jonathan!
I am familiar with the error in general, but I am using vanilla packages by the
vendor (FreeBSD) which should not have any funky optimisations. Also, my
colleague ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778
--- Comment #1 from Hannes Hauswedell ---
Here is the intermediate code:
https://hauswedell.net/lambda.ii.xz
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The beautiful intermediate code that I attached (Yes, I know it's huge), ICEs
with the very non-descriptive message of:
g++9: internal com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92480
Hannes Hauswedell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Great to see that immediate functions have already landed!
But compiling the following on godbolt with gcc-trunk fails:
consteval int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92441
--- Comment #2 from Hannes Hauswedell ---
(In reply to Martin Liška from comment #1)
> Can you please provide full command line of the GCC?
g++10 -std=c++17 -fconcepts dna4_test.ii
This triggers the ICE as mentioned in the original report. For
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 47206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47206&action=edit
intermediate code
Intermediate code is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075
--- Comment #6 from Hannes Hauswedell ---
(In reply to Jason Merrill from comment #5)
> Author: jason
> Date: Tue Nov 5 11:46:54 2019
> New Revision: 277825
>
> URL: https://gcc.gnu.org/viewcvs?rev=277825&root=gcc&view=rev
> Log:
> PR c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83083
Hannes Hauswedell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930
--- Comment #6 from Hannes Hauswedell ---
I can confirm that my problem is not fixed by the patch from this PR. Do you
want me to open a new issue or will this be reopened?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548
--- Comment #6 from Hannes Hauswedell ---
To make the test only complain about the current issue, change line 20 in
include/seqan3/std/span to
```
#if 0
```
Regards,
Hannes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548
--- Comment #5 from Hannes Hauswedell ---
(In reply to Marek Polacek from comment #4)
> (In reply to Hannes Hauswedell from comment #2)
> > Any news on this issue? We are using this pattern in some rather central
> > files in our library and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #8 from Hannes Hauswedell ---
Anything I can do to help resolve this? We have library code that breaks
because of the issue and since 9.2 is deployed everywhere that 9.1 was used,
this is very disruptive...
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #7 from Hannes Hauswedell ---
Any news here? It's still marked unconfirmed.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #5 from Hannes Hauswedell ---
> (In reply to Marek Polacek from comment #4)
> The ICE was fixed by r266816.
But not for GCC9?
I can confirm that GCC 9.2.1 snapshot from 20190817 still triggers the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91608
--- Comment #2 from Hannes Hauswedell ---
I am on the following snapshot
> g++10 (FreeBSD Ports Collection) 10.0.0 20190818 (experimental)
so I am likely not entirely up to date!
If it has been fixed already, we can close this of course!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075
--- Comment #3 from Hannes Hauswedell ---
Any news on this? (I don't know if GCC7 is scheduled to have a patch release at
all anymore, but if yes, it would still be great to have this...)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
With gcc10 and std=c++2a I am seeing
error: top-level comma expression in array subscript is deprecated
[-Werror=comma-subscript]
on
return names[meta::find_index::value];
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #3 from Hannes Hauswedell ---
Created attachment 46790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46790&action=edit
intermediate code generated from GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #2 from Hannes Hauswedell ---
Created attachment 46789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46789&action=edit
intermediate code generated from GCC9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #1 from Hannes Hauswedell ---
Created attachment 46788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46788&action=edit
intermediate code generated from GCC8
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 46787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46787&action=edit
intermediate code generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #12 from Hannes Hauswedell ---
Is this resolved for GCC 8.4 now?
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The rather simple example below fails to build on GCC8 in C++17 mode, but
passes on GCC7, GCC9 and trunk in C++17 mode. It fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075
--- Comment #1 from Hannes Hauswedell ---
I see that this has changed for snapshots of GCC9 now, thanks a lot! Is this
something you can backport to to GCC7 and GCC8 that would really help
downstream projects to reduce needless use of MACROs!
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194
--- Comment #1 from Hannes Hauswedell ---
Created attachment 45600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45600&action=edit
ii generated with -std=c++2a
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 45599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45599&action=edit
ii generated with -std=c++17
I have a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 45597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45597&action=edit
intermediate file
Building a test case in o
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
In GCC9 a call to replace_extension() no longer removes the extension from a
filesystem::path. This leads to very unexpected beha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089
--- Comment #10 from Hannes Hauswedell ---
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089
--- Comment #5 from Hannes Hauswedell ---
PS: I do have to correct myself: since range-v3 now auto-detects concept
support the tests are indeed built with -fconcepts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089
--- Comment #4 from Hannes Hauswedell ---
Created attachment 45541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45541&action=edit
third ICE
g++9 -std=c++17 -fconcepts -Wall -Wextra take_while.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089
--- Comment #3 from Hannes Hauswedell ---
Created attachment 45540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45540&action=edit
second ICE
g++9 -std=c++17 -fconcepts -Wall -Wextra concat.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089
--- Comment #2 from Hannes Hauswedell ---
Created attachment 45539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45539&action=edit
first ICE
Build with:
g++9 -std=c++17 -fconcepts -Wall -Wextra variant.cpp
y: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The 1.0-beta branch of the range-v3 library triggers various (seemingly
different) ICEs in GCC9. GCC7 and GCC8 seem not affected. This is even without
-std=c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
Hannes Hauswedell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
D
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Concepts in C++20 are happening and the overlap with the concepts TS is very
significant which opens the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83083
--- Comment #1 from Hannes Hauswedell ---
*polite ping*
Any chance this will change for gcc9? I know some changes are pending for the
San Diego WG21 meeting, but these are only additions to what is already merged
in the DS. It would be great to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Take the following code:
template
struct S
{
template
requires false
friend void foobar(S, t2) {}
};
int main()
{
foobar(S{}, int{});
}
Obviously the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588
--- Comment #1 from Hannes Hauswedell ---
Created attachment 44410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44410&action=edit
intermediate file
build with -std=c++17 -fconcepts
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I have attached a code sample below and will provide an intermediate file that
shows that various forms of initialisation fail to build, while equivalent (at
least some) pass [all that are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
--- Comment #3 from Hannes Hauswedell ---
(In reply to Jonathan Wakely from comment #2)
> It might be reasonable for GCC to silently ignore attributes that use an
> unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or
> [[acme:
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
[this issue is split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243 ]
Unknown attributes currently produce warnings in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243
Hannes Hauswedell changed:
What|Removed |Added
Keywords||rejects-valid
Summary|unk
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following small example which is valid according to the current draft
standard (not just the Concepts TS, with the exception of the bool keyword):
#include
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243
--- Comment #2 from Hannes Hauswedell ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Hannes Hauswedell from comment #0)
> > Note that I am not even setting -Wall or -Wextra.
>
> As documented, -Wattributes is enabled by default
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following code (based on
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0479r1.html)
int main()
{
if (1 == 2) [[unlikely]]
throw int{};
return 2;
}
produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212
--- Comment #1 from Hannes Hauswedell ---
Created attachment 44294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44294&action=edit
second intermediate file
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 44293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44293&action=edit
rename to .gz and gunzip
% uname -a
FreeBSD 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84925
--- Comment #1 from Hannes Hauswedell ---
Created attachment 43693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43693&action=edit
intermediate file from crash
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 43692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43692&action=edit
code that crashes gcc-8
I have att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84855
--- Comment #5 from Hannes Hauswedell ---
Sure, that follows from the definition "For each identifier, a variable whose
type is "reference to std::tuple_element::type" is introduced".
This wouldn't have to be implemented like this, though...
My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84855
--- Comment #2 from Hannes Hauswedell ---
Thanks for your explanation, I went to through cppreferences again and the
behaviour is now clear to me, although I still wonder why in the case of an
lvalue as "input", the step through the intermediary
everity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Created attachment 43647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43647&action=edit
example
If I do
fooba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411
--- Comment #3 from Hannes Hauswedell ---
I agree that the problem is related, I don't however think that solving PR82625
will solve the problem, as it would require me to multiversion every function
in my part of the subgraph, or not?
i.e.: giv
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
[is this component entry correct?]
The documentation of FMV states: This aim of this project is to make it really
easy for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81276
Hannes Hauswedell changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
Currently GCC offers the Concepts TS via -fconcepts, but it doesn't seem to
offer the modified/reduced Concepts merged into C++2a. For forward
compatibility checks of existing code and als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #13 from Hannes Hauswedell ---
(In reply to Andreas Tobler from comment #12)
> Will soon commit a fix, for gcc6/7/8 on FreeBSD > 9.3. Older gcc's and OS
> releases will not be supported by this fix.
Thanks a lot!
But is there no cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #10 from Hannes Hauswedell ---
> Could you please tell us the FreeBSD version and arch you run on?
uname -ra
FreeBSD celegans.imp.fu-berlin.de 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
Fri Jul 21 02:08:28 UTC 2017
r...@releng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #6 from Hannes Hauswedell ---
Sorry, I forgot the stack trace. It wasn't helpful to me:
(gdb) bt
#0 uw_frame_state_for (context=context@entry=0x801c00e20,
fs=fs@entry=0x801c00b70) at
/wrkdirs/usr/ports/lang/gcc7-devel/work/gcc-7-2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #4 from Hannes Hauswedell ---
> the complete command line that triggers the bug;
/usr/local/bin/g++7 -Wl,-rpath -Wl,/usr/local/lib/gcc7/ -std=c++11 -pthread
test_thread.cpp
(g++7 could be g++6 g++6 or g++8)
> Are you linking to libp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #1 from Hannes Hauswedell ---
Created attachment 42411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42411&action=edit
test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82634
Hannes Hauswedell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
See the attached code. It compiles "fine" everywhere, but the resulting binary
crashes in some situations:
It runs fine on all comp
1 - 100 of 126 matches
Mail list logo
