[Bug libstdc++/70472] is_copy_constructible>>::value is true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 Askar Safin changed: What|Removed |Added Resolution|--- |INVALID Status|NEW

[Bug c++/104066] New: "extern constinit long (* const syscall_reexported) (long, ...);" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself

, not to function pointer itself Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: safinaskar at mail

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #11 from Askar Safin --- (In reply to Jonathan Wakely from comment #10) > I wish people would just learn how enums work, it's not that complicated. Okey, now I understand everything. Now I see that, well, -fstrict-enums silences warn

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #9 from Askar Safin --- (In reply to Andrew Pinski from comment #8) > Yes because they have different semantics ... So, you mean that "enum class" is less strict than normal enums? This is very strange. Today I normally use "enum cl

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 Askar Safin changed: What|Removed |Added CC||safinaskar at mail dot ru --- Comment #7

[Bug libstdc++/70472] is_copy_constructible>>::value is true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 --- Comment #8 from Askar Safin --- Recently I noticed this bug can be easily fixed simply by manually implementing is_copy_constructible. So, please, apply the fix. And same for other type traits (is_copy_assignable etc). #include #include #i

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70530 Askar Safin changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70530 Askar Safin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70530 --- Comment #4 from Askar Safin --- DR 2468 says that after "a = std::move (a)" state of a is unspecified. So three-move self-swap will be unspecified, too. You just said, that self-swap is not undefined, i. e. it is defined. Okey, so to make it

[Bug c++/78770] New: error: 'bar' was not declared in this scope. note: suggested alternative: 'bar'

D Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: safinaskar at mail dot ru Target Milestone: --- Consider this code: struct foo { friend void bar (void); void baz (void) { bar ();

[Bug libstdc++/70472] is_copy_constructible>>::value is true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 --- Comment #3 from Askar Safin --- (In reply to Jonathan Wakely from comment #2) > It's not required, and it would be impossible to require it in general. The > problem is that std::vector does have a copy constructor, so the trait value > is tr

[Bug libstdc++/70530] New: You should probably add addressof (a) != addressof (b) check to std::swap

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: safinaskar at mail dot ru Target Milestone: --- C++ standard says standard library functions may assume rvalue reference arguments are unique, i. e. are not aliased to any

[Bug libstdc++/70472] is_copy_constructible>>::value is true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 --- Comment #1 from Askar Safin --- Also, this code doesn't compile: http://paste.debian.net/422907/ and I think this is related to this bug. If I decomment noexcept line, it compiles

[Bug libstdc++/70472] New: is_copy_constructible>>::value is true

ty: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: safinaskar at mail dot ru Target Milestone: --- Consider this code: #include #include #include #include int main (void) { std::cout << std::is_copy_constructible>>::value <<

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #23 from Askar Safin --- Please remove {0} warning at least in cases where {0} is obviously OK (such as addrinfo)

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 Askar Safin changed: What|Removed |Added CC||safinaskar at mail dot ru --- Comment #21

[Bug c/52160] New: gdb ignores line "bar: if(foo)goto bar;"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160 Bug #: 52160 Summary: gdb ignores line "bar: if(foo)goto bar;" Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: