[Bug c++/110765] [13 regression] constraints on parameters of derived type in CRTP base

[h2+bugs at fsfe dot org via Gcc-bugs]

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.

[Bug c++/110765] New: [13 regression] constraints on parameters of derived type in CRTP base

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110765

Bug ID: 110765
   Summary: [13 regression] constraints on parameters of derived
type in CRTP base
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: 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=edit
GCC12's intermediate code; build with -std=c++20

I have large parts of library code that fail to build with GCC13, although they
build with GCC10-12 and Clang-16.

I have attached GCC12's intermediate code that compiles cleanly with GCC12 but
fails to build with GCC13. The error is the same as when building the actual
code. See logs below.

Playing a bit around with the code seems to indicate that constrained friend
declarations in the CRTP base that references the derived class could be the
problem:

Triggering code:
```cpp
friend constexpr auto tag_invoke(custom::to_char, derived_type const a)
noexcept
requires(requires { { a.to_char() }; })
{
return a.to_char();
}
```

Workaround:
```cpp
friend constexpr auto tag_invoke(custom::to_char, std::same_as
auto const a) noexcept
requires(requires { { a.to_char() }; })
{
return a.to_char();
}
```

It seems that GCC13 tries to check the constraints on the derived class earlier
than previous GCCs and Clang, and apparently before the type is complete.


Passes:
% g++12 --version 
g++12 (FreeBSD Ports Collection) 12.2.0
%g++12 -std=c++20 a-test.ii
%

Fails:
% g++13 --version
g++13 (FreeBSD Ports Collection) 13.1.1 20230701
% g++13 -std=c++20 a-test.ii
In file included from /usr/local/lib/gcc12/include/c++/bits/stl_pair.h:60,
 from /usr/local/lib/gcc12/include/c++/bits/stl_algobase.h:64,
 from /usr/local/lib/gcc12/include/c++/vector:60,
 from
/home/hannes/devel/biocpp-core/include/bio/alphabet/nucleotide/dna4.hpp:16,
 from test.cpp:1:
/usr/local/lib/gcc12/include/c++/type_traits:1522:12: error: expected
identifier before '__is_nothrow_convertible'
 1522 | struct __is_nothrow_convertible
  |^~~~
/usr/local/lib/gcc12/include/c++/type_traits:1522:12: error: expected
unqualified-id before '__is_nothrow_convertible'
/usr/local/lib/gcc12/include/c++/type_traits:3083:66: error: template argument
2 is invalid
 3083 | __is_nothrow_convertible>
  |  ^~
In file included from /usr/local/lib/gcc12/include/c++/memory:76,
 from
/home/hannes/devel/biocpp-core/include/bio/meta/detail/type_inspection.hpp:21,
 from
/home/hannes/devel/biocpp-core/include/bio/alphabet/concept.hpp:22,
 from
/home/hannes/devel/biocpp-core/include/bio/alphabet/base.hpp:20,
 from
/home/hannes/devel/biocpp-core/include/bio/alphabet/nucleotide/nucleotide_base.hpp:16,
 from
/home/hannes/devel/biocpp-core/include/bio/alphabet/nucleotide/dna4.hpp:18:
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:536:15: error: expected
identifier before '__remove_cv'
  536 | using __remove_cv = typename remove_cv<_Up>::type;
  |   ^~~
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:536:27: error: expected '('
before '=' token
  536 | using __remove_cv = typename remove_cv<_Up>::type;
  |   ^
  |   (
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:536:27: error: expected
type-specifier before '=' token
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:536:27: error: expected
unqualified-id before '=' token
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:542:69: error: wrong number
of template arguments (1, should be 2)
  542 | __not_, __remove_cv<_Up>>>
>;
  | ^~
/usr/local/lib/gcc12/include/c++/type_traits:635:12: note: provided for
'template struct std::is_same'
  635 | struct is_same;
  |^~~
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:542:71: error: template
argument 1 is invalid
  542 | __not_, __remove_cv<_Up>>>
>;
  |   ^
/usr/local/lib/gcc12/include/c++/bits/unique_ptr.h:542:73: error: template
argument 2 is invalid
  542 | __not_, __remove_cv<_Up>>>
>;
  |
^
/usr/local/lib/gcc12/include/c++/type_traits: In instantiation of 'struct
std::is_nothrow_destructible':
/home/hannes/devel/biocpp-core/include/bio/alphabet/base.hpp:26

[Bug c++/109425] mismatched argument pack lengths while expanding

[h2+bugs at fsfe dot org via Gcc-bugs]

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.

[Bug c++/109425] New: mismatched argument pack lengths while expanding

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425

Bug ID: 109425
   Summary: mismatched argument pack lengths while expanding
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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 } ->
std::convertible_to; };

template 
struct my_tuple
{

template 
requires ((sizeof...(Ts) == sizeof...(T2s)) && (weakly_eq_comparable && ...))
friend bool operator==(my_tuple const & lhs, my_tuple const & rhs)
{
return true;
}
};

int main()
{
my_tuple m1;
}
```

See also:
https://godbolt.org/z/3eEjT589o

The error is:
```
: In instantiation of 'struct my_tuple':
:20:26:   required from here
:11:86: error: mismatched argument pack lengths while expanding
'weakly_eq_comparable'
   11 | requires ((sizeof...(Ts) == sizeof...(T2s)) &&
(weakly_eq_comparable && ...))
  |   
~~^~~~
Compiler returned: 1
```

Clang>=13 accepts this code.

I am not sure if this is related to #107853, because I am not getting an ICE,
but it seems like the problems (or their solutions) could be related.

Thank you!

[Bug libstdc++/107471] mismatching constraints in common_iterator

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107471

--- Comment #2 from Hannes Hauswedell  ---
Great, thanks!

[Bug libstdc++/107471] New: mismatching constraints in common_iterator

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107471

Bug ID: 107471
   Summary: mismatching constraints in common_iterator
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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>) && copyable<_It>
  class common_iterator
  {

// ...

template _Sent2>
friend class common_iterator;
```

The constraints are mismatching. GCC (falsely) accepts this, but clang fails,
see also 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107470

[Bug c++/107470] New: GCC falsely accepts friend declaration with mismatching requirements

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107470

Bug ID: 107470
   Summary: GCC falsely accepts friend declaration with
mismatching requirements
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  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()
{
S s;
}


The code is accepted by GCC and rejected by clang. However, if the friend
declaration is fully unconstrained, it is also rejected by GCC.

Code like this exists in libstdc++ which clang stumbles over (I will create a
separate library issue for that).

[Bug c++/107202] New: inheriting assignment operators from CRTP-base

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107202

Bug ID: 107202
   Summary: inheriting assignment operators from CRTP-base
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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(Base &&) = default;
//Base & operator=(Base const &) = delete;
//Base & operator=(Base &&) = delete;

#if OPTION == 1
Derived const & operator=(Derived &)
{
return static_cast(*this);
}
#elif OPTION == 2
Derived const & operator=(Derived &) const
{
return static_cast(*this);
}
#elif OPTION == 3
Derived const & operator=(Derived const &)
{
return static_cast(*this);
}
#elif OPTION == 4
Derived const & operator=(Derived const &) const
{
return static_cast(*this);
}
#endif
};

struct D : Base
{
D() = default;
D(D const &) = default;
D(D &&) = default;
//D & operator=(D const &) = delete;
//D & operator=(D &&) = delete;

using Base::operator=;
};

int main()
{
D d1;
D d2;
d1 = d2;
}
```


OPTION == 0 → no valid overload (expected!)
OPTION == 1 → well-formed
OPTION == 2 → ambiguous overload
OPTION == 3 → no valid overload
OPTION == 4 → no valid overload

Clang behaves the same as GCC. MSVC never sees any valid overloads.

My assumption was that implicit assignment operators are inhibited in all cases
(this is also shown by OPTION == 0), but that any of the inherited operators
should be valid. Should the implicit deletion of the assignment-operator in D
prevent inheriting the user-defined assignment operators from Base, why does
this affect some of them and not others?

[Bug c++/107104] semantics of __builtin_constant_p within static_assert and return value

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #1 from Hannes Hauswedell  ---
It seems that __builtin_constant_p does not indicate whether something *can be*
a constant but whether *it is* a constant.
If you evaluate it in a non-const-context, the expression passed as argument
may or may not be evaluated at compile-time, so the value of
__builtin_constant_p may or may not be 1.

This example illustrates the behaviour:

```cpp
constexpr void foobar() {}// → test() returns 0 or 1
//consteval void foobar() {}  // → test() returns 1

#define TEST_EXPR (foobar(), 0)

int test() {
static_assert(__builtin_constant_p(TEST_EXPR));
return __builtin_constant_p(TEST_EXPR);
}
```


To enforce evaluation in a const-context, you can define a macro like this:

#define IS_CONSTEXPR(...) std::integral_constant::value

[Bug libstdc++/106669] incorrect definition of viewable_range ("more madness with move-only views")

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669

Hannes Hauswedell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Hannes Hauswedell  ---
According to LWG, this "works as intended". I will try to prepare some more
arguments for changing this, but in any case it is not a GCC issue –– yet ;-)

[Bug libstdc++/106669] incorrect definition of viewable_range ("more madness with move-only views")

[h2+bugs at fsfe dot org via Gcc-bugs]

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) if that expression is well-formed and the decayed type of E
models view.

This will make references to move-only views pick the second option (ref_view).

[Bug c++/106669] New: incorrect definition of viewable_range ("more madness with move-only views")

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669

Bug ID: 106669
   Summary: incorrect definition of viewable_range ("more madness
with move-only views")
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  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.

Before views were allowed to be move-only, S was not considered a view, but `S
&` was considered viewable (it would just be wrapped in ref_view). Now, S is a
valid view, and S (no-ref!) is also a viewable range. But apparently the
requirements for viewable_range were not correctly updated, because `S &` is
now no longer viewable. The code in the standard is the following:

template
  concept viewable_­range =
range &&
((view> && constructible_­from, T>) ||
 (!view> &&
  (is_lvalue_reference_v || (movable> &&
!is-initializer-list;

For any `T &` where T is a view but not copy-constructible, this concept will
evaluate to false. I am assuming this is an LWG issue and will report on the
reflector unless you see a good reason for the current behaviour?


#include 
#include 

struct S : std::string_view, std::ranges::view_base
{
S() = delete;
S(S const &) = delete;
S(S &&) = default;
S & operator=(S const &) = delete;
S & operator=(S &&) = default;

S(std::string_view v) : std::string_view{v} {}
};

static_assert(std::ranges::view); // fails expectedly on
gcc11.3, passes on gcc12.1
static_assert(std::ranges::viewable_range);   // fails expectedly on
gcc11.3, passes on gcc12.1
static_assert(std::ranges::viewable_range); // passes on gcc11.3, fails
unexpectedly on gcc12.1

int main()
{
S s{"foo"};
s | std::views::filter([] (char) { return true;}); // this fails in gcc12.1
}

[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)

[h2+bugs at fsfe dot org via Gcc-bugs]

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

[Bug c++/106369] [12/13 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515

[h2+bugs at fsfe dot org via Gcc-bugs]

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 change prevents the bug from triggering. Maybe that helps in pinning it
down?

[Bug c++/106369] New: ICE in output_constructor_regular_field, at varasm.cc:5515

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369

Bug ID: 106369
   Summary: ICE in output_constructor_regular_field, at
varasm.cc:5515
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
backtrace

Also reproducible with GCC-10.3 (varasm.c:5254).

I don't know if this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103285 since that is in the
fortran component.

[Bug c++/106320] New: [10 regression] build failure (due to view requirement changes?)

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320

Bug ID: 106320
   Summary: [10 regression] build failure (due to view requirement
changes?)
   Product: gcc
   Version: 10.4.0
Status: UNCONFIRMED
  Severity: normal
  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 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904

#include 
#include 

int main()
{
auto l = std::views::transform([](auto v)
{
auto x = int{}; //!BROKEN - remove this capture and it will work
return v | std::views::transform([x](auto v2)
{
return v2;
});
});

std::vector> v{{5, 6, 7}};
v | l | std::views::join;
}

[Bug c++/106202] New: internal compiler error: in move_fn_p, at cp/decl.cc:14907

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106202

Bug ID: 106202
   Summary: internal compiler error: in move_fn_p, at
cp/decl.cc:14907
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
backtrace

ICE when using generated comparison operators. 

Ubuntu 22.04
g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
g++-12 (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f]

[Bug c++/101803] CTAD fails for nested designated initializers

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803

--- Comment #8 from Hannes Hauswedell  ---
OK, thank you anyway!

[Bug c++/101803] CTAD fails for nested designated initializers

[h2+bugs at fsfe dot org via Gcc-bugs]

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!

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904

--- Comment #19 from Hannes Hauswedell  ---
Thanks a lot!

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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?
> 
> No, because the current priority is gcc 12.

I just realised that the issue was actually not that old, sorry for bugging
you! Looking forward to GCC12 :)


(In reply to Jonathan Wakely from comment #10)
> I think we should backport it except for the removal of the default
> constructors for {back_,front_,}insert_iterator, ostream_iterator and
> basic_istream_view. If we keep those default constructible on the release
> branches I think the chance of breaking any code is minimal.

That's sounds like a good plan :+1:

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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 patch-level releases? Otherwise, it will be
forgotten. And the longer we wait with a decision, the less likely it will be
that it can be backported.

Thank you!

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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 like to sum up the points that I see in favour of deviating from
that rule:
* GCC10 is still young, the chances that codebases have come to rely on exactly
this behaviour is lower now than it will be when e.g. the next Debian stable is
released. Backporting will reduce breakage in the long run.
* As you have pointed out, the feature has been hidden behind the non-standard
c++20-flag. People had to explicitly opt-in to use this feature and were made
aware that it is experimental.
* The concept becomes more general than before, and all standard library types
that previously met its requirements still meet the old requirements (standard
library views are still default-initializable). So I expect *most* old code
that uses views to just keep working.
* I don't know if this counts as an argument, but I would argue that people
whose code breaks because they rely on something not being a view that is now
considered a view, are also the kind of people who will be able to fix this
quickly ;-)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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 GCC compilers are being
shipped with the old behaviour, the more code will be broken, or not?
With GCC10 being in common distributions like Debian stable, we are actively
contributing to the old definition being around...

Since views were introduced in GCC10 (and are not an old and established
feature), I think that the situation here is different from for other "breaking
changes" and that we should quickly try to homogenize the GCC behaviour for as
many people as possible. I think that was also the reasoning for "allowing" the
change in the IS.

[Note that I was not strongly in favour of this change, I am just scared of
writing code that might change behaviour unknowingly soon ]

[Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904

Bug ID: 103904
   Summary: [defect fix] Please backport P2325R3 to 10 and 11
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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:

#include 

struct T : std::ranges::view_base
{
T() = delete;

char * begin() { return nullptr; }

char * end() { return nullptr; }

};

static_assert(std::ranges::range);
static_assert(std::ranges::view);


Since this change is quite significant and considered a defect-fix, could you
backport it to GCC10 and GCC11?

Thank you very much!

[Bug c++/101803] CTAD fails for nested designated initializers

[h2+bugs at fsfe dot org via Gcc-bugs]

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?

[Bug c++/101803] New: CTAD fails for nested designated initializers

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803

Bug ID: 101803
   Summary: CTAD fails for nested designated initializers
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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;
};

struct Outer2
{
Inner s{};
};

template 
struct Outer
{
Inner s{};
};

int main()
{
Outer2 o21{ .s = {} };// works
Outer2 o22{ .s = Inner{ .i = 1} };// works
Outer2 o23{ .s = { .i = 1} }; // works

Outer2 o24{ .s{} };   // works
Outer2 o25{ .s{Inner{ .i = 1} } };// works
Outer2 o26{ .s{ .i = 1} };// works

Outer o1{ .s = {} };// works
Outer o2{ .s = Inner{ .i = 1} };// works
//Outer o3{ .s = { .i = 1} }; // does not

Outer o4{ .s{} };   // works
Outer o5{ .s{Inner{ .i = 1} } };// works
//Outer o6{ .s{ .i = 1} };// does not
}

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

[h2+bugs at fsfe dot org via Gcc-bugs]

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 that
returns 0, 1, 2, 3 or 4 depending on which feature level is available on the
current computer.

How is my example different from
https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html (other than
using the new feature levels)?

Thanks

[Bug c/101696] New: Function multiversioning not usable with new x86-64-v*

[h2+bugs at fsfe dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696

Bug ID: 101696
   Summary: Function multiversioning not usable with new x86-64-v*
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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 thing would be to have a small "arch_detect" program that gives me the
feature level as return value:

__attribute__ ((target ("default")))
int foo ()
{
// The default version of foo.
return 0;
}

__attribute__ ((target ("arch=x86-64")))
int foo ()
{
return 1;
}

__attribute__ ((target ("arch=x86-64-v2")))
int foo ()
{
return 2;
}
__attribute__ ((target ("arch=x86-64-v3")))
int foo ()
{
return 3;
}

__attribute__ ((target ("arch=x86-64-v4")))
int foo ()
{
return 4;
}

int main ()
{
return foo();
}


This builds fine but always returns 0 -- independent of whether I build the
binary without -march or with -march=x86-64-v4.

Curiously, if I add the following overload:

__attribute__ ((target ("sse4.2")))
int foo ()
{
// The default version of foo.
return 7;
}

it will no longer build without -march=x86-64-v4, complaining that "no
dispatcher was found for the versioning attributes". If I add -march=x86-64-v4,
it will build without errors but always return 7 and not the feature level.

What am I missing?

[Bug c++/92778] [8/9 regression] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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 do to further narrow this down?

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778

Hannes Hauswedell  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Hannes Hauswedell  ---
Any news on this issue?

I have created up to date intermediate files here:

https://hauswedell.net/gcc_ice_20200123/

Compile with -std=c++17 -fconcepts -fopenmp -pthread -lz -lbz2 
On FreeBSD also -lexecinfo
On GCC7/8, also add /path/to/libstdc++fs.a

The code triggers ICEs in GCC8 and GCC9 but not in GCC7, so I am marking this
"ice-on-valid-code" and I would also consider it a regression.

These are the compiler versions tested:

WORKS: g++7 (FreeBSD Ports Collection) 7.5.0
ICEs: g++8 (FreeBSD Ports Collection) 8.3.0
ICEs: g++9 (FreeBSD Ports Collection) 9.2.1 20200118

Do you need anything else from me to confirm this issue?

Thank you very much!

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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 just reported that she is seeing the same on gcc9 on Ubuntu -- I'll
try to confirm that myself.

The code is not expected to build on trunk/gcc10 because of other known and
reported issues (strip_typedefs...), so I think what you are seeing is not the
same thing.

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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

[Bug c++/92778] New: ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778

Bug ID: 92778
   Summary: ICE: Illegal instruction signal terminated program
cc1plus
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  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 compiler error: Illegal instruction signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

The command to build the intermediate code is:

g++9 -std=c++17 -fconcepts -pthread -fopenmp lambda.ii

Reproducible with the compiler versions:
g++9 (FreeBSD Ports Collection) 9.2.0 
g++9 (FreeBSD Ports Collection) 9.2.1 20191123

[Bug c++/92480] Parameters in consteval functions should be constant expressions.

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92480

Hannes Hauswedell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Hannes Hauswedell  ---
Ah, well, I am not actually sure that this is supposed to work :(

[Bug c++/92480] New: Parameters in consteval functions should be constant expressions.

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92480

Bug ID: 92480
   Summary: Parameters in consteval functions should be constant
expressions.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  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 foobar(int i)
{
static_assert(i > 1);
return i + 2;
}

int main()
{
return foobar(3);
}

with

:3:21: error: non-constant condition for static assertion

3 | static_assert(i > 1);

  |   ~~^~~

:3:21: error: 'i' is not a constant expression

But i should be a constant expression inside an immediate function, or not?

[Bug c++/92441] [10 regression] ICE: in strip_typedefs, at cp/tree.c:1681

[h2+bugs at fsfe dot org]

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 The resulting
binary to link correctly, gtest has to be added as a static library.

The full invocation that generates the intermediate code is this:

cd /home/hannes/devel/seqan3-build/release10/alphabet/nucleotide &&
/usr/local/bin/ccache /usr/local/bin/g++10  -DSEQAN3_HAS_BZIP2=1
-DSEQAN3_HAS_ZLIB=1
-I/home/hannes/devel/seqan3-build/release10/vendor/googletest/googletest/include
-I/home/hannes/devel/seqan3/test/include -I/home/hannes/devel/seqan3/include
-isystem /home/hannes/devel/seqan3/submodules/sdsl-lite/include -isystem
/home/hannes/devel/seqan3/submodules/range-v3/include -isystem
/home/hannes/devel/seqan3/submodules/cereal/include 
-ftemplate-backtrace-limit=0 -fdiagnostics-color=always -std=c++17 -fconcepts
-save-temps -O3 -DNDEBUG   -pedantic -Wall -Wextra -Werror
-DNO_WARN_X86_INTRINSICS -pthread -o CMakeFiles/dna4_test.dir/dna4_test.cpp.o
-c /home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp



> And please paste output of when '-v' is added.

Using built-in specs.
COLLECT_GCC=g++10
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc10/gcc/x86_64-portbld-freebsd12.0/10.0.0/lto-wrapper
Target: x86_64-portbld-freebsd12.0
Configured with:
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20191103/configure
--enable-multilib --with-build-config=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc10
--libexecdir=/usr/local/libexec/gcc10 --program-suffix=10
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc10/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc10 --build=x86_64-portbld-freebsd12.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191103 (experimental) (FreeBSD Ports Collection) 
COLLECT_GCC_OPTIONS='-std=c++17' '-fconcepts' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc10/gcc/x86_64-portbld-freebsd12.0/10.0.0/cc1plus
-fpreprocessed /tmp/dna4_test.ii -quiet -dumpbase dna4_test.ii -mtune=generic
-march=x86-64 -auxbase dna4_test -std=c++17 -version -fconcepts -o
/tmp//ccmJ4Que.s
GNU C++17 (FreeBSD Ports Collection) version 10.0.0 20191103 (experimental)
(x86_64-portbld-freebsd12.0)
compiled by GNU C version 10.0.0 20191103 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++17 (FreeBSD Ports Collection) version 10.0.0 20191103 (experimental)
(x86_64-portbld-freebsd12.0)
compiled by GNU C version 10.0.0 20191103 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e7b6ef0d246e27cc0ec9ebf3a0ce4fdc
In file included from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/concepts.hpp:30,
 from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/range/concepts.hpp:28,
 from /home/hannes/devel/seqan3/include/seqan3/std/ranges:28,
 from
/home/hannes/devel/seqan3/include/seqan3/core/concept/core_language.hpp:19,
 from
/home/hannes/devel/seqan3/include/seqan3/alphabet/concept.hpp:17,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/../alphabet_constexpr_test_template.hpp:10,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp:8:
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/access.hpp:222:76:
internal compiler error: in strip_typedefs, at cp/tree.c:1681
  222 | is_swappable_with,
iter_reference_t>::value>
  |
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/92441] New: [10-regression] ICE: in strip_typedefs, at cp/tree.c:1681

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92441

Bug ID: 92441
   Summary: [10-regression] ICE: in strip_typedefs, at
cp/tree.c:1681
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
intermediate code

Intermediate code is attached. Build with -std=c++17 -fconcepts.

Possibly related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 (but not
fixed by the proposed patch).

GCC version: g++10 (FreeBSD Ports Collection) 10.0.0 20191103

Log:

In file included from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/concepts.hpp:30,
 from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/range/concepts.hpp:28,
 from /home/hannes/devel/seqan3/include/seqan3/std/ranges:28,
 from
/home/hannes/devel/seqan3/include/seqan3/core/concept/core_language.hpp:19,
 from
/home/hannes/devel/seqan3/include/seqan3/alphabet/concept.hpp:17,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/../alphabet_constexpr_test_template.hpp:10,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp:8:
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/access.hpp:222:76:
internal compiler error: in strip_typedefs, at cp/tree.c:1681
  222 | is_swappable_with,
iter_reference_t>::value>
  |
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[h2+bugs at fsfe dot org]

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=gcc=rev
> Log:
>   PR c++/88075 - Don't require 'bool' in a concept definition.
> 
>   * parser.c (cp_parser_decl_specifier_seq): Support C++20
>   concept-definition syntax without 'bool'.
> 
> Added:
> branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/no-bool1.C
> Modified:
> branches/gcc-8-branch/gcc/cp/ChangeLog
> branches/gcc-8-branch/gcc/cp/parser.c


Thanks a lot for this change!

Does this work with -fconcepts and if yes can we also get it for GCC7? Thanks a
lot!

[Bug c++/83083] c++2a concepts without -fconcepts

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83083

Hannes Hauswedell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Hannes Hauswedell  ---
fixed by current trunk

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[h2+bugs at fsfe dot org]

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?

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #5 from Hannes Hauswedell  ---
Created attachment 47148
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47148=edit
intermediate code

I am still seeing:

/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/basic_iterator.hpp:463:23:
internal compiler error: in lazily_declare_fn, at cp/method.c:2372
  463 | Cur>::readable_iterator_associated_types_base;
  |   ^~~


in the snapshot from 20191027.

Was the fix merged later or is my issue different?

Intermediate code is attached. Build with -std=c++17 -fconcepts

Thank you for your help!

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

[h2+bugs at fsfe dot org]

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

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

[h2+bugs at fsfe dot org]

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 bug literally breaks 90% of our unit tests so
> > we can't keep track of other gcc10 issues or try the new concepts support...
> > 
> > Thank you for your help!
> 
> BTW, is the library publicly accessible?  If it is, I could try to compile
> it when I have a fix for this to make sure it's resolved.

Sure, thanks for looking into this!

The library is available here:
https://github.com/seqan/seqan3/

Instructions for setting up unit tests are available here:
https://docs.seqan.de/seqan/3-master-user/setup_tests.html

The currently failing tests are visible here:
http://cdash.seqan.de/index.php?project=SeqAn3
Under "Nightly: unit", "FreeBSD unit Debug g++10 -std=c++2a"
Note that due to the recent arrival of C++20 concepts in gcc-trunk, other
things are currently broken with so you need to explicitly provide "-std=c++17
-fconcepts" (and not trust the auto detection of our cmake config).

Making e.g. "view_to_lower_test" should trigger the problem from this PR
(although I just saw that it also has a seemingly unrelated problem with not
finding std::span, just ignore that).

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #2 from Hannes Hauswedell  ---
Any news on this issue? We are using this pattern in some rather central files
in our library and the bug literally breaks 90% of our unit tests so we can't
keep track of other gcc10 issues or try the new concepts support...

Thank you for your help!

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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!

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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!

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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.

[Bug c++/91608] [10 warning] wrong comma-subscript warning

[h2+bugs at fsfe dot org]

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!

[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[h2+bugs at fsfe dot org]

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...)

[Bug c++/91608] New: [10 warning] wrong comma-subscript warning

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91608

Bug ID: 91608
   Summary: [10 warning] wrong comma-subscript warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 that's not a top-level comma-expression. It's part of the template
specialisation...

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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=edit
intermediate code generated from GCC10

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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=edit
intermediate code generated from GCC9

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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=edit
intermediate code generated from GCC8

[Bug c++/91607] New: [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607

Bug ID: 91607
   Summary: [9 regression] internal compiler error: in equal, at
cp/constexpr.c:1088
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: 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=edit
intermediate code generated from GCC7

Recently some tests in our CI have started to fail. I am pretty sure they did
not fail with 9.1.0; I can verify they do not fail with GCC7, GCC8 and GCC10.

I have attached intermediate code for our test case, generated with different
compiler versions and each tested also with different compiler versions.

The command to invoke is:
g++ -std=c++17 -fconcepts custom_alphabet_test_GCC7.ii
./gtest_project/src/gtest_project-build/googletest/libgtest.a
./gtest_project/src/gtest_project-build/googletest/libgtest_main.a


Results for intermediate code generated from GCC7:
  * GCC7 builds
  * GCC8 builds
  * GCC9: internal compiler error: in nothrow_spec_p, at cp/except.c:1247
  * GCC10: builds

Results for intermediate code generated from GCC8:
  * GCC8 builds
  * GCC9: internal compiler error: in equal, at cp/constexpr.c:1088
  * GCC10: builds

Results for intermediate code generated from GCC9:
  * GCC9: internal compiler error: in equal, at cp/constexpr.c:1088
  * GCC10: builds

Results for intermediate code generated from GCC10:
  * GCC10: builds

The exact compiler versions are:
g++7 (FreeBSD Ports Collection) 7.4.0
g++8 (FreeBSD Ports Collection) 8.3.0
g++9 (FreeBSD Ports Collection) 9.2.0
g++10 (FreeBSD Ports Collection) 10.0.0 20190818 (experimental)

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521

--- Comment #12 from Hannes Hauswedell  ---
Is this resolved for GCC 8.4 now?

[Bug c++/90897] New: user defined conversion operators ambiguous in GCC8, but not GCC7 and GCC9

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90897

Bug ID: 90897
   Summary: user defined conversion operators ambiguous in GCC8,
but not GCC7 and GCC9
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: 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 on all compilers in
C++14 mode.

Tested versions:
g++7 (FreeBSD Ports Collection) 7.4.0
g++8 (FreeBSD Ports Collection) 8.3.0
g++9 (FreeBSD Ports Collection) 9.1.0
g++10 (FreeBSD Ports Collection) 10.0.0 20190602 (experimental)

Apparently the code is correct for C++17, but GCC8 was not updated accordingly?

Thanks for your help!

struct S2
{
constexpr S2() = default;
constexpr S2(S2 const &) = default;
constexpr S2(S2 &&) = default;
constexpr S2& operator=(S2 const &) = default;
constexpr S2& operator=(S2 &&) = default;

constexpr S2 (int const &) {}
};

struct S
{
operator int()
{
return 3;
}

operator S2()
{
return S2{};
}
};

int main()
{
S2 s = static_cast(S{});
}

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #17 from Hannes Hauswedell  ---
I don't want to sound presumptuous, but can we raise the importance of this
issue? Otherwise we will get a gcc9 release that breaks all projects using the
soon-to-be-released 1.0 release of range-v3.

I think that is quite significant or not?

Thank you for your work on GCC!

[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[h2+bugs at fsfe dot org]

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!

Thanks!

[Bug libstdc++/89194] [9 regression] build failure with libstdc++ with std=c++2a

[h2+bugs at fsfe dot org]

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=edit
ii generated with -std=c++2a

[Bug libstdc++/89194] New: [9 regression] build failure with libstdc++ with std=c++2a

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194

Bug ID: 89194
   Summary: [9 regression] build failure with libstdc++ with
std=c++2a
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
ii generated with -std=c++17

I have a library test case that builds and passes with GCC8 and GCC9 when both
are given -std=c++17. But if I pass -std=c++2a to GCC9 the build fails with
long obscure templates errors in . If I however generate intermediate
code in std=c++17 mode and then build this intermediate code in c++2a mode,
everything works so I am convinced this is an issue of the standard library.

I have attached both intermediate files. They both still require gtest, but
maybe someone knowledgeable can already deduce something from the compiler
error and/or the diff of the intermediate files?

Otherwise I can prepare intermediate files without gtest dependency tomorrow.

These compile:
g++9 -std=c++17 -fconcepts -pthread gcc9_stdcpp17.ii libgtest.a libgtest_main.a
g++9 -std=c++2a -fconcepts -pthread gcc9_stdcpp2a.ii libgtest.a libgtest_main.a
This one does not:
g++9 -std=c++2a -fconcepts -pthread gcc9_stdcpp2a.ii libgtest.a libgtest_main.a

GCC version:
g++9 (FreeBSD Ports Collection) 9.0.1 20190127 (experimental)

[Bug c++/89191] New: [9 regression] ICE in reshape_init_r, at cp/decl.c:6172

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89191

Bug ID: 89191
   Summary: [9 regression] ICE in reshape_init_r, at
cp/decl.c:6172
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
intermediate file

Building a test case in our repo with GCC9 ICEs, but works fine in GCC7 and
GCC8.

I have attached the intermediate file. It builds with:
g++9 -std=c++2a -fconcepts global_affine_unbanded_test.ii

(note that because of some builtin stuff the intermediate file itself doesn't
build with GCC8, but I can provide GCC8's ii if you want to).

GCC9 version is:
g++9 (FreeBSD Ports Collection) 9.0.1 20190127 (experimental)

[Bug libstdc++/89117] New: [9 regression] filesystem::path's replace_extension() broken?

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117

Bug ID: 89117
   Summary: [9 regression] filesystem::path's replace_extension()
broken?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  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 behaviour without prior warning
or error.

Example:

#include 
#include 

int main()
{
std::filesystem::path p{"/tmp/abc.txt.gz"};
std::cout << p << '\t' << p.extension() << '\n';
p.replace_extension(); // remove .gz
std::cout << p << '\t' << p.extension() << '\n';
}

hannes@fbsdmain /tmp % g++8 -std=c++17  test.cpp -lstdc++fs
hannes@fbsdmain /tmp % ./a.out
"/tmp/abc.txt.gz"   ".gz"
"/tmp/abc.txt"  ".txt"
hannes@fbsdmain /tmp % g++9 -std=c++17  test.cpp -lstdc++fs
hannes@fbsdmain /tmp % ./a.out
"/tmp/abc.txt.gz"   ".gz"
"/tmp/abc.txt"  ".gz"


These are my tested versions:
g++8 (FreeBSD Ports Collection) 8.2.1 20190118
g++9 (FreeBSD Ports Collection) 9.0.0 20190113 (experimental)

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089

--- Comment #10 from Hannes Hauswedell  ---
Thanks for the quick fix!

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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.

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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=edit
third ICE

g++9 -std=c++17 -fconcepts -Wall -Wextra take_while.cpp

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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=edit
second ICE

g++9 -std=c++17 -fconcepts -Wall -Wextra concat.cpp

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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=edit
first ICE

Build with:
g++9 -std=c++17 -fconcepts -Wall -Wextra variant.cpp

[Bug c++/89089] New: [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89089

Bug ID: 89089
   Summary: [9 regression] various ICEs in range-v3's 1.0 branch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: 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++2a or -fconcepts.

% g++9 --version
g++9 (FreeBSD Ports Collection) 9.0.0 20190113 (experimental)

Here are the reports: https://github.com/ericniebler/range-v3/issues/1011

I can provide intermediate files in this PR, but it would probably be good to
just pull the above branch and build the test suite since that might reveal
more issues?

[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968

Hannes Hauswedell  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Hannes Hauswedell  ---
Yes, this was fixed, thanks!

[Bug c++/88075] New: [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075

Bug ID: 88075
   Summary: [feature-request] allow "concept" instead of "concept
bool" with -fconcepts
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  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 possibility to write code in a dialect that is
accepted by both `-std=c++17 -fconcepts` and `-std=c++2a`. This is a huge bonus
for GCC over other implementations, because many long-term supported operating
systems ship GCC7 and won't pick up new compilers with full c++20 support for a
long time.

The only thing that prevents using the common subset is that concepts are
introduced by "concept bool" in the TS, but only by "concept" in the draft
standard. Instead of burdening the c++20 implementation with being compatible
to the TS, it would be really great if you could change the implementation of
the TS on GCC7 and GCC8 to also accept just "concept".

Note that I do not suggest backporting any features or other changes, this is
just about a small syntactical change that would allow cleanly writing code
that targets older and newer GCC versions at the same time. I assume this would
be greatly appreciated by quite a few libraries that currently employ different
concept-compatibility layers like range-v3, nanorange, cmstl2 and others. I
also expect more people will be interested in targeting the common concepts
dialect as Clang is picking up Concepts soon (the c++2a-feature branch works
quite well already).

[Bug c++/83083] c++2a concepts without -fconcepts

[h2+bugs at fsfe dot org]

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 have concepts as per the DS in GCC9. Thank you!

[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093

Hannes Hauswedell  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #2 from Hannes Hauswedell  ---
Constraints on friend member functions seemed to be stripped entirely,
therefore making two functions with only different constraints appear the same:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86978

[Bug c++/86978] New: constraints for friend functions ignored

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86978

Bug ID: 86978
   Summary: constraints for friend functions ignored
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 friend function should never be available, but the code compiles
just fine, because apparently the constraints on friend functions are ignored
entirely? This took quite long to find, because there is no diagnostic of any
kind, just wrong behaviour.

Tested with GCC 7.3 and 8.1 on godbolt.org

I think this explains https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 as
well, because of the constraints are stripped from friend functions than two
functions which differ only in constraints appear as redefinitions.

[Bug c++/86588] peculiar build issue using range-v3

[h2+bugs at fsfe dot org]

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=edit
intermediate file

build with -std=c++17 -fconcepts

[Bug c++/86588] New: peculiar build issue using range-v3

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588

Bug ID: 86588
   Summary: peculiar build issue using range-v3
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 commented out fail, the last two are the only
that pass].

Since range-v3 pulls in a large amount of code the intermediate files are quite
large and I have as of yet been unsuccessful in reducing this to something that
still fails, but I hope someone with more expertise can track the compiler
while it tries/fails to deduce the type.

tested versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180712
g++8 (FreeBSD Ports Collection) 8.1.1 20180713

For reference also the issue at range-v3:
https://github.com/ericniebler/range-v3/issues/860


std::string vec{"foo\nbar"};
seqan3::detail::view_take_line v1(ranges::view::all(vec));

assert("foo" == std::string(v1));
assert(ranges::BidirectionalRange());
assert(ranges::View());

// auto v2 = v1 | ranges::view::reverse;// #1

// auto v2 = ranges::reverse_view{v1};// #2

using t = ranges::reverse_view;

// auto v2 = t(v1); // #3
// auto v2 = t{v1}; // #3b

// t v2 = t(v1);// #4
// t v2 = t{v1};// #4b

// t v2 = v1;   // #5

t v2(v1);// #6
t v3{v1};// #6b


assert("oof" == std::string(v2));

[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17

[h2+bugs at fsfe dot org]

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::rocketboots]] they probably aren't expecting GCC to handle it.
> 
> This could mean silently ignoring typos like [[ngu::unused]] but it's
> arguably  easier to spot a typo like "ngu" than to spot "warn_unsued_result"
> or "alwasy_inlne".

That's true, but I would still argue that *by default* GCC should also ignore
[[foobar]] if it doesn't know it. Let me elaborate:

I develop a header-only library and want to start including [[likely]] so that
for newer compilers things "start working" as soon as they pick up the feature.
I am ok with [[likely]] not being interpreted by the compiler, that's why a
choose an attribute to begin with and not some low-level magic, but if it
works, all the better. This is precisely what attributes are designed for and
why they are supposed to be ignored if unknown.
BUT if this code generates warnings there is a problem: obviously I don't want
to tell downstream developers that "it's ok, just ignore the warnings" (since I
have a header-only library I cannot pre-decide this). And I cannot workaround
this in code short of introducing a MACRO. Note that not being able to
workaround the warning makes this different from almost all other warnings I am
aware of. 

And wrapping future attributes in MACROs just to be able to ship code that is
warning/error-free clearly defeats the intent of the standard, or not? I am not
sure, maybe we should take the question to a reflector?

[Bug c++/86368] New: an unknown [[attribute]] should not trigger a warning in C++17

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368

Bug ID: 86368
   Summary: an unknown [[attribute]] should not trigger a warning
in C++17
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  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 (-Wattributes), however
since C++17 the standard clearly states that C++ attributes (those with
[[name]]) should be ignored when unknown:
 "Any attribute-token that is not recognized by the implementation is ignored." 

The purpose here is to let programmers add attributes that may not be supported
on a platform (yet) and not force them to workaround their non-existance on
that platform (be it via macros or extra compiler arguments). 

I would argue that is a very important aspect of attributes and that it will
become increasingly important when more C++2a attributes are implemented in GCC
and clang ([[likely]] [[unlikely]], [[expects: ]]...). I would even suggest not
including a warning with -Wall or -Wextra, because an unknown attribute is and
in the future even more likely will be part of the design and not an error.
Moreover there is no clean way to workaround the warning, other than using
macros which is not a clean way ;-)
A stand-alone flag would of course still be useful to detect mistyped known
attributes, but this should not trigger by default and IMHO also not with
regular quality control (-Wall -Wextra).

[Bug c++/86243] unknown attribute before throw causes hard error

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243

Hannes Hauswedell  changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|unknown attributes causing  |unknown attribute before
   |hard error  |throw causes hard error

--- Comment #3 from Hannes Hauswedell  ---
I have changed the title to reflect that this report is only about the error
related to the throw and will open a separate issue for the warning.

[Bug c++/86269] New: ICE with intermediate concepts notation

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86269

Bug ID: 86269
   Summary: ICE with intermediate concepts notation
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 >
concept bool IntegralOrIntegralRef = std::is_integral_v;

template 
auto foo(t && v)
{
return v;
}

int main()
{
int i = 7;
return foo(i);
}


produces:

% g++7 -std=c++17 -fconcepts test.cpp
test.cpp:6:11: internal compiler error: in tsubst, at cp/pt.c:13657
 template 
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

Checked versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180607
g++8 (FreeBSD Ports Collection) 8.1.1 20180615
g++9 (FreeBSD Ports Collection) 9.0.0 20180610 (experimental)

Thanks for your work on GCC!

[Bug c++/86243] unknown attributes causing hard error

[h2+bugs at fsfe dot org]

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 and you need to use
> -Wno-attributes to disable it.

Hm, IMHO this could maybe be reconsidered now that attributes are a
standardised feature of the language and the standard explicitly states:
"Any attribute-token that is not recognized by the implementation is ignored."
I think this was added precisely to make upgrades to new attributes seamless
and to support different platform-specific ones. This is not the case if they
produce warnings, especially by default.

BUT this bug report is primarily about the error and not the warning!

[Bug c++/86243] New: unknown attributes causing hard error

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243

Bug ID: 86243
   Summary: unknown attributes causing hard error
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 an error:

% g++7 -std=c++17 test.cpp
test.cpp: In function 'int main()':
test.cpp:3:18: error: expected identifier before '[' token
 if (1 == 2) [[unlikely]]
  ^
test.cpp: In lambda function:
test.cpp:4:9: error: expected '{' before 'throw'
 throw int{};
 ^
test.cpp: In function 'int main()':
test.cpp:4:9: error: expected ';' before 'throw'

This strongly looks like a bug. If one encloses the if-block in braces, I
instead get a warning:

int main()
{
if (1 == 2) [[unlikely]]
{
throw int{};
}

return 2;
}

results in:

% g++7 -std=c++17 test.cpp
test.cpp: In function 'int main()':
test.cpp:3:17: warning: attributes at the beginning of statement are ignored
[-Wattributes]
 if (1 == 2) [[unlikely]]
 ^
Note that I am not even setting -Wall or -Wextra. Even then I would think that
unknown attributes should just be silently ignored as suggested by the
standard, or not?

Thanks for your help!

Tested versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180531
g++8 (FreeBSD Ports Collection) 8.1.1 20180608
g++9 (FreeBSD Ports Collection) 9.0.0 20180603 (experimental)

[Bug c++/86212] ICE in tsubst_copy, at cp/pt.c:15935

[h2+bugs at fsfe dot org]

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=edit
second intermediate file

[Bug c++/86212] New: ICE in tsubst_copy, at cp/pt.c:15935

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212

Bug ID: 86212
   Summary: ICE in tsubst_copy, at cp/pt.c:15935
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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=edit
rename to .gz and gunzip

% uname -a
FreeBSD  11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40
UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
amd64

% g++9 --version
g++9 (FreeBSD Ports Collection) 9.0.0 20180603 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

The ICE does not occur on GCC7 and GCC8. I have attached intermediate files. 

This is the build error log:
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:
In instantiation of 'constexpr
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args =
{__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type  = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]':
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:405:50:
  required from 'static constexpr ranges::v3::adaptor_cursor_t
ranges::v3::view_adaptor::begin_cursor_(D&) [with D =
const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; Derived =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; BaseRng =
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >; ranges::v3::cardinality Cardinality =
(ranges::v3::cardinality)-1; ranges::v3::adaptor_cursor_t =
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >;
typename std::decay(), 42))>::type =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor;
typename std::decay(),
42))>::type>().begin(declval()))>::type =
__gnu_cxx::__normal_iterator >]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_adaptor.hpp:423:193:
  required by substitution of 'template > >,
__gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >,
__gnu_cxx::__normal_iterator > > > >())), int>::type  > constexpr
decltype
(ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor_(declval()))
ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >, (ranges::v3::cardinality)-1>::begin_cursor >() const [with D =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; int
_concept_requires_421 = 42; typename std::enable_if<((_concept_requires_421 ==
43) || (typename ranges::v3::concepts::Same::same > >,
__gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >,
__gnu_cxx::__normal_iterator > > > >())), int>::type  = 0]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/range_access.hpp:175:35:
  required by substitution of 'template static constexpr decltype
(static_cast(rng).begin_cursor())
ranges::v3::range_access::begin_cursor(Rng&, int) [with Rng = const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >]'
/home/mi/h4nn3s/devel/seqan3/submodules/range-v3/include/range/v3/view_facade.hpp:35:68:
  

[Bug c++/84925] ICE with segfault in __PRETTY_FUNCTION__ (regression over gcc-7)

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84925

--- Comment #1 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Created attachment 43693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43693=edit
intermediate file from crash

[Bug c++/84925] New: ICE with segfault in __PRETTY_FUNCTION__ (regression over gcc-7)

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84925

Bug ID: 84925
   Summary: ICE with segfault in __PRETTY_FUNCTION__ (regression
over gcc-7)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  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=edit
code that crashes gcc-8

I have attached a test.cpp

g++-7 (Debian 7.3.0-8) builds this fine.
g++-8 (Debian 8-20180308-1) segfaults on this with

test.cpp:537:25: internal compiler error: Speicherzugriffsfehler
 auto name_ptr = __PRETTY_FUNCTION__;

I have also attached an intermediate file.

Thanks for your help!

[Bug c++/84855] structered bindings require "decomposed" type to be copy'able

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84855

--- Comment #5 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Sure, that follows from the definition "For each identifier, a variable whose
type is "reference to std::tuple_element<i, E>::type" is introduced".
This wouldn't have to be implemented like this, though...

My original intuition (and probably that of others) was that 
auto CR [ a, b ] = f;

leads to 

auto CR a = std::get<0>(f);
auto CR b = std::get<1>(f);

where CR can be "", "&", "&&" or "const &".

Instead something like this happens:
auto CR e = f;
auto && a = std::get<0>(e);
auto && b = std::get<1>(e);

I assume this design was chosen to be able to materialise temporaries and I
don't see an obvious way of handling that with a different design. But I still
feel like it is less intuitive in the general case and in my case also prevents
the plan (because I explicitly don't want perfect forwarding).

But that's a different matter and I will stop wasting your dev time ;-)

[Bug c++/84855] structered bindings require "decomposed" type to be copy'able

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84855

--- Comment #2 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
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 is not required to be
elided.

[Bug c++/84855] New: structered bindings require "decomposed" type to be copy'able

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84855

Bug ID: 84855
   Summary: structered bindings require "decomposed" type to be
copy'able
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: 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=edit
example

If I do

foobar f; // has tuple-like interface
auto [ a, b ] = f;

Then for some reason foo needs to be copyable and I don't understand why, i.e.
perceive this as a bug, although both GCC and Clang require it.

I have attached a file that illustrates this. I would assume that invoking the
structed bindings just calls get() twice on the f, but gobolting the attached
code without optimisations reveals that indeed f is being copied.

And the actual problem is that explicitly deleting the copy-constructor of
foobar makes the build fail.

Like I said, maybe I am missing something here, but why would there be a copy
involved of type f. [Obviously there is copy involved of the members of f,
depending on the return type of get(), but that's a different matter from f].

Thank you for your help!

Confirmed on
g++-7 (Debian 7.3.0-8)
g++-8 (Debian 8-20180308-1)
clang version 5.0.1-2

[Bug ipa/83411] function multiversioning should clone the entire sub-callgraph

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411

--- Comment #3 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
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.: given

f() → g()

if both f() and g() are multiversioned, PR82625 will result in only one
dispatch, but given

f() → g() → h()

if only f() and h() are multiversioned, it would still to double-dispatch or
not?

[Bug tree-optimization/83411] New: function multiversioning should clone the entire sub-callgraph

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411

Bug ID: 83411
   Summary: function multiversioning should clone the entire
sub-callgraph
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  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 developer to specify multiple versions of a function, each catered
to a specific target ISA feature. GCC then takes care of creating the
dispatching code necessary to execute the right function version.

This sounds really cool, but in practice there is the huge problem that FMV
does not apply to nested functions calls forcing the developer to move the FMV
to the bottom of the callgraph incurring a possibly huge run-time penalty due
to calling the dispatch ridiculously often.

I have described this problem in detail on my blog¹, but I think it should be
quite evident to you. I would humbly suggest adding something like

__attribute__((target_clone_trees("default", "popcnt")))

that recursively also clones the nested function calls (without additional
dispatch steps and working independent of inlining or not). For optimisations
that are then generated automatically or by builtins this would already solve
all my problems :)

For manually curated SIMD code however this touches on another problem with
current FMV: one cannot rely on macros for feature detection. To fix this one
needs another mechanism to be able to find out which features are available for
the code block currently being compiled. I am not a compiler expert, but I
guess it is not possible to make macros work, simply because they are evaluated
much earlier. But could the compiler provide constexpr feature variables to the
code?
Then one could simply "clone_tree" early and "if constexpr (__has_sse4) ...
else ..." in the actual funcion.

Thanks for reading all of this and you work on GCC in general!

¹ https://hannes.hauswedell.net/post/2017/12/09/fmv/

[Bug c++/81276] Function multiversioning doesn't work with C++ templates

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81276

Hannes Hauswedell <h2+bugs at fsfe dot org> changed:

   What|Removed |Added

 CC|        |h2+bugs at fsfe dot org

--- Comment #2 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
target_clones does however work with templates:
https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,source:'%23include+%3Ccstdint%3E%0A%0Atemplate+%3Ctypename+int_t%3E%0A__attribute__((target_clones(%22default%22,+%22popcnt%22)))%0Auint64_t+pc(int_t+const+v)%0A%7B%0Areturn+__builtin_popcountll(v)%3B%0A%7D%0A%0Aint+main()%0A%7B%0Afor+(uint64_t+i+%3D+0%3B+i+%3C+1!'000!'000!'000%3B+%2B%2Bi)%0Avolatile+uint64_t+ret+%3D+pc(i)%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:g72,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',trim:'0'),libs:!(),options:'-O3+-DNDEBUG',source:1),l:'5',n:'0',o:'x86-64+gcc+7.2+(Editor+%231,+Compiler+%231)',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

[Bug c++/83083] New: c++2a concepts without -fconcepts

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83083

Bug ID: 83083
   Summary: c++2a concepts without -fconcepts
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 also for comparison with other
compilers (which will hopefully start supporting C++2a concepts sometime next
year), it would very, very helpful if GCC8 provided the new
concepts-light-light via the regular -std=c++2a switch (without -fconcepts).

Is this a planned feature or not a priority? Will it make it into GCC8? I know
these things are not trivial, but it seems like it's "only" a subset of already
existing features that "just" needs to be rewired.

Thanks a lot for your work on this!

[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

--- Comment #13 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
(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 chance of getting a fix for gcc5? Not even via patch in the
FreeBSD port (if not doable via gcc5 trunk)?
Because we would need to selectively disable gcc5 then (while gcc49 and >5
would still work which is kind of akward).

[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

--- Comment #10 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
> 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...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

For completeness, these are the GCC versions installed:
% pkg info | grep gcc
gcc-ecj-4.5Eclipse Java Compiler used to build GCC Java
gcc49-4.9.4_5  GNU Compiler Collection 4.9
gcc5-5.4.0_4   GNU Compiler Collection 5
gcc6-6.4.0_2   GNU Compiler Collection 6
gcc7-devel-7.2.1.s20171012 GNU Compiler Collection 7
gcc8-devel-8.0.0.s20171008 GNU Compiler Collection 8

gcc49-4.9.4_5 works, the later ones don't.

[Bug c++/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

--- Comment #6 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
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-20171012/libgcc/unwind-dw2.c:1257
#1  0x000800df4f87 in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x801816730, context=context@entry=0x801c00e20) at
/wrkdirs/usr/ports/lang/gcc7-devel/work/gcc-7-20171012/libgcc/unwind.inc:155
#2  0x000800df5525 in _Unwind_ForcedUnwind (exc=0x801816730,
stop=0x8010127b0, stop_argument=) at
/wrkdirs/usr/ports/lang/gcc7-devel/work/gcc-7-20171012/libgcc/unwind.inc:207
#3  0x000801012613 in ?? () from /lib/libthr.so.3
#4  0x00080101242b in pthread_exit () from /lib/libthr.so.3
#5  0x000801004bcd in ?? () from /lib/libthr.so.3
#6  0x000801a01000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x801c01000

Anything else I can do?

[Bug c++/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

--- Comment #4 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
> 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 libpthread?

I am calling -pthread (or -lpthread), but ldd says:
% ldd a.out
a.out:
libstdc++.so.6 => /usr/local/lib/gcc7//libstdc++.so.6 (0x800825000)
libm.so.5 => /lib/libm.so.5 (0x800bba000)
libgcc_s.so.1 => /usr/local/lib/gcc7//libgcc_s.so.1 (0x800de5000)
libthr.so.3 => /lib/libthr.so.3 (0x800ffc000)
libc.so.7 => /lib/libc.so.7 (0x801224000)

The broken combinations crash after a few iterations:
% ./a.out
Hallo
Waited successfully. Was joinable: 1
Hallo
Waited successfully. Was joinable: 1
Hallo
Waited successfully. Was joinable: 1
Hallo
Waited successfully. Was joinable: 1
Hallo
Waited successfully. Was joinable: 1
Hallo
[1]2613 segmentation fault (core dumped)  ./a.out

The crash happens when calling .joinable(). If we skip the joinable check it
crashes on .join().

[Bug c++/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

--- Comment #1 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
Created attachment 42411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42411=edit
test program

[Bug c++/82634] C++11 std::thread::join

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82634

Hannes Hauswedell <h2+bugs at fsfe dot org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Hannes Hauswedell <h2+bugs at fsfe dot org> ---
oops, seems like my browser wrongly created this.

[Bug c++/82635] New: std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

Bug ID: 82635
   Summary: std::thread's join broken on FreeBSD with all GCCs >=
5
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: 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 compilers on Linux; it runs fine on all versions of clang
on FreeBSD and on GCC-4.9 on FreeBSD.

With GCC>=5 (including current 8-snapshot) the program crashes after 5
(sometimes 6) iterations. This may depend on the hardware, I can't say for
sure. It is also strange how it is only triggered after multiple iterations.

The problem must have been introduced in the last months, I know for sure that
it did not happen in June. However it seems strange that it affects all GCCs
down to version 5. Maybe something that was backported?

I am CCing FreeBSD's port maintainer in case something happened on the
packaging side of things.