: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 0xd34df00d at gmail dot com
Target Milestone: ---
This program:
#include
namespace
{
constexpr uint64_t CalcHash (std::string_view name)
{
return 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #4 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Also, while experimenting I've found that adding a non-initializing capture
element to the list somewhat mitigates the issue. That is, if the capture list
looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #3 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Not yet. Should I?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #1 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Created attachment 33387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33387&action=edit
Successfully compiling code.
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 0xd34df00d at gmail dot com
Created attachment 33386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33386&action=edit
Failing code
Passing a lambda cop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #2 from Georg Rudoy <0xd34df00d at gmail dot com> 2012-05-24
20:04:56 UTC ---
(In reply to comment #1)
> Foo f = Foo(2);
> assert( DoFoo( f ) );
>
> Undefined behaviour.
Yes, it is. And isn't it happening
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Bug #: 53479
Summary: Control flow analysis too alarming with switch over an
enum class
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED