[Bug rust/105913] gccrs doesn't compile on 32-bit targets

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #7 from Thomas Schwinge  ---
But now really assuming fixed via additional
 "Fix remaining misuses of format
specifiers on 32-bit targets".

Re: [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[Jan Hubicka via Gcc-bugs]

> > For this one it's PRE hoisting *b across the endless loop (PRE handles
> > calls as possibly not returning but not loops as possibly not 
> > terminating...)
> > So it's a different bug.
> 
> Btw, C++ requiring forward progress makes the testcase undefined.
In my understanding access to volatile variable is a forward progres:
In a valid C++ program, every thread eventually does one of the
following:

   -terminate
   -makes a call to an I/O library function
   -performs an access through a volatile glvalue
   -performs an atomic operation or a synchronization operation 

I think one can also replace volatile access by atomics: we only need to
know the side effects of that operation.
Honza

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> > For this one it's PRE hoisting *b across the endless loop (PRE handles
> > calls as possibly not returning but not loops as possibly not 
> > terminating...)
> > So it's a different bug.
> 
> Btw, C++ requiring forward progress makes the testcase undefined.
In my understanding access to volatile variable is a forward progres:
In a valid C++ program, every thread eventually does one of the
following:

   -terminate
   -makes a call to an I/O library function
   -performs an access through a volatile glvalue
   -performs an atomic operation or a synchronization operation 

I think one can also replace volatile access by atomics: we only need to
know the side effects of that operation.
Honza

[Bug c++/106085] New: It's unclear what the __has_trivial* builtins do after P0848 (Conditionally Trivial Special Member Functions)

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

Bug ID: 106085
   Summary: It's unclear what the __has_trivial* builtins do after
P0848 (Conditionally Trivial Special Member Functions)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roi.jacobson1 at gmail dot com
  Target Milestone: ---

I'm currently in the process of implementing P0848 for Clang, and I'm wondering
what to do about the __has_trivial_* builtins, especially since they consider
deleted functions as trivial, which goes against the spirit of 'deleted
functions are ineligible and should not affect the type traits'.

I tried to play with it a bit in GCC and the builtin seems pretty inconsistent:

#include 

template
struct A {
A() = delete;
A() requires std::same_as = delete;
};

template
struct B {
B();
B() requires std::same_as = delete;
};

template
struct C {
C();
C() requires std::same_as = default;
};

static_assert(__has_trivial_constructor(A));
static_assert(!__is_trivially_constructible(A));

static_assert(!__has_trivial_constructor(B));
static_assert(!__is_trivially_constructible(B));

static_assert(__has_trivial_constructor(C));
static_assert(__is_trivially_constructible(C));


Is there logic behind this? Those builtins are technically deprecated in Clang
but I would like to support GCC compatibility if possible.

If not, it might be a good idea to add a warning about using those builtins or
potentially start to deprecate them in GCC as well.

[Bug c++/106086] New: ICE: trying to capture 'this' in instantiation of generic lambda

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 106086
   Summary: ICE: trying to capture 'this' in instantiation of
generic lambda
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

Following code generates ICE

#include 
#include 
#include 

template 
struct foo {
constexpr auto operator()(std::same_as auto...) const -> int {
return 0;
}
};

template 
struct bar : foo<_size>
{
constexpr auto operator()(std::array index) const -> int
{
return [&](std::index_sequence) {
return foo<_size>::operator()(index[i]...);
}(std::make_index_sequence<_size>());
}
};

bar<1> b;
int i = b({0}); // <-- ERROR

:18:58: internal compiler error: trying to capture 'this' in
instantiation of generic lambda

live: https://godbolt.org/z/TKGWME5aG

A couple of similar, closed bugs show up in the search so I've added them as
see-also. 105788 might be the same but it's listed as "ice-on-invalid-code" and
I'm fairly sure mine is valid (it refers to 100291).

[Bug sanitizer/86899] [10/11/12/13 regression] TSAN incorrect warning: control reaches end of non-void function

[dimhen at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Dmitry G. Dyachenko  ---
r13-1213 PASS for me
r13-1164 FAIL for me