[Bug c++/83769] New: Statement expression inside lambda defined and evaluated in global scope fails to compile with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83769 Bug ID: 83769 Summary: Statement expression inside lambda defined and evaluated in global scope fails to compile with optimizations Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: giel+gcc at mortis dot eu Target Milestone: --- Created attachment 43089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43089&action=edit small example reproducing the problem Evaluating a statement expression (such as used by htons on glibc) inside a lambda defined at global scope (used for Immediately Invoked Lambda Expression (IILE) used as initializer for a global constant) successfully compiles at -O0 but fails to compile at -O1 or higher. I'm building with -std=c++11. I'm getting this error message: > : In lambda function: > :9:29: error: statement-expressions are not allowed outside functions > nor in template-argument lists >addr.sin_port = htons(KLocalPort); A reduced example is attached. I initially discovered this on GCC 4.8.2 (after discovering that a release build fails on CI, while a debug system on my local dev machine succeeds). Testing on godbolt.org confirms that this behaviour was already present on GCC 4.5.3 already (-std=c++0x was necessary on that version) and is still present on GCC 7.2. I also tested Clang (on godbolt.org only) and notice that versions 3.0 up until and including 3.5.1 have the same behaviour (succeed with -O0, fail with complaint about statement expression at file scope with -O1). Clang 3.6 no longer has this problem though.
[Bug c++/118014] New: address computation for coroutine frame differs between BasePromise and MostDerivedPromise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118014
Bug ID: 118014
Summary: address computation for coroutine frame differs
between BasePromise and MostDerivedPromise
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: giel+gcc at mortis dot eu
Target Milestone: ---
Created attachment 59845
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59845&action=edit
reproduction scenario
Given the signature of
std::coroutine_handle::from_promise(Promise& p)
(from: )
I expect to be able to do
struct MostDerivedPromise final : BasePromise {
auto await_transform(auto&& x) {
return
wrapped_awaitable(std::coroutine_handle::from_promise(*this));
}
};
And then be able to use the produced handle both to access the (base part of
the) promise and to call .resume()/.destroy()/.done() on it.
Converting back to the promise reference works just fine. But .resume() and
.destroy() end up calling a NULL function pointer.
This appears to be caused by the conversion functions from/to handles&promises
depend on the alignment of the promise:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/coroutine-passes.cc;h=c0d6eca7c070bbff391a07ce51d05d7010ff24c9;hb=04696df09633baf97cdbbdd6e9929b9d472161d3#l118
And obviously the alignment of MostDerivedPromise is unknown to
std::coroutine_handle causing wrong offset calculations for this
scenario.
I've attached a reproduction scenario that has a single assertion for my
expectation that the underlying address produced for
coroutine_handle::from_promise and
coroutine_handle is the same.
That assertion holds when MostDerivedPromise' alignment is equal to that of
BasePromise but fails otherwise.
[Bug c++/118014] address computation for coroutine frame differs between BasePromise and MostDerivedPromise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118014 --- Comment #1 from Giel --- While different from PR104177 I believe that Arsen's patch for that would also solve this bug: [PATCH 2/2] c++/coroutines: handle (new-)extended alignment [PR104177] (https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663295.html) This is because that patch makes the offset between the promise and coroutine frame (pointer) dependent *only* on sizeof(void*) and thus independent of alignof(T). Eliminating any differences between alignof(Base) and alignof(Derived).
[Bug c++/118107] New: false warning: "${inactive union member} may be used uninitialized" (in constructor call activating another, empty struct member, as union member)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118107
Bug ID: 118107
Summary: false warning: "${inactive union member} may be used
uninitialized" (in constructor call activating
another, empty struct member, as union member)
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: giel+gcc at mortis dot eu
Target Milestone: ---
Created attachment 59909
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59909&action=edit
reproduction scenario
Attached I have a completely cut down example that triggers a false positive
warning "X may be uninitialized". Also the same on compiler explorer:
https://godbolt.org/z/ErWaT5KMq
It only happens with -O1 *and* -fsanitize=undefined (but *not*
-fsanitize=undefined,address) (and -Wall -Wextra of course). When increasing
code size it needs -O2 at least to trigger.
The warning triggers on a call to the default constructor. Which activates an
*empty struct* as a union member. But the warning complains about the
*inactive* (non-empty) union member (maybe) being used uninitialized.
[Bug c++/116952] Error on lambda NTTP argument to type constraint in template parameter list of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116952
Giel changed:
What|Removed |Added
CC||giel+gcc at mortis dot eu
--- Comment #3 from Giel ---
I just ran into the same issue when trying to create meta-concepts and used
lambdas to approximate 'concept template parameters':
https://godbolt.org/z/5qaradfeE
```
#include
// Convert a concept to a functor that can be passed as an NTTP
#define CONCEPTARG(C, ...) \
([] () consteval \
{ return C<_first_concept_arg_ __VA_OPT__(,) __VA_ARGS__>; })
// Convert functor NTTP back to concept
template
concept apply_concept_fun = ConceptParam.template operator()();
// Example meta-concept that combines others
template
concept all_of = (apply_concept_fun && ...);
template I>
constexpr auto foobar(I i)
{
return i * static_cast(2);
}
```
Note that funnily enough just moving the concept check to a `requires` clause
causes compilation to pass:
```
template
requires all_of
constexpr auto foobar(I i)
{
return i * static_cast(2);
}
```
[Bug c++/116952] Error on lambda NTTP argument to type constraint in template parameter list of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116952
--- Comment #4 from Giel ---
Also taking `decltype()` to convert it to a type-param doesn't
help (Clang still accepts it):
```
template
concept A = F()();
template T>
constexpr auto fun(T) {}
```
