[Bug c++/93415] New: Previous declaration of template without default arguments leads to incorrect overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93415
Bug ID: 93415
Summary: Previous declaration of template without default
arguments leads to incorrect overload resolution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
#include
template
void f (int);
template
void f (int)
{
std::cout << "correct - int\n";
}
template
void f (char)
{
std::cout << "wrong - char\n";
}
int main ()
{
f (0);
return 0;
}
The above program prints "wrong - char" with gcc, however just removing
declartion of `f` without default arguments leads to expected result. It is
very annoying issue because do-nothing forward declarations may lead to
unexpected hard to find bugs. Other compilers seem to handle this case
properly.
[Bug c++/88893] New: Forward declaring of enum class with visibility results in -Wattributes false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88893
Bug ID: 88893
Summary: Forward declaring of enum class with visibility
results in -Wattributes false positive.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
The following program
enum class azaza;
enum class __attribute__ ((visibility ("default"))) azaza
{
};
compiled with no arguments gives:
:2:53: warning: type attributes ignored after type is already defined
[-Wattributes]
2 | enum class __attribute__ ((visibility ("default"))) azaza
| ^
Since making enum classes visible may be needed w.r.t libc++ type_info
behavior. This warning turns out to be a bit annoying in this case since
clang++ compiles code fine.
This problem was partially fixed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407
But with forward declaration old behavior still shows through.
[Bug libstdc++/83607] std::boyer_moore_searcher is slow searching through arrays of std::byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83607 Sergey Semushin changed: What|Removed |Added CC||Predelnik at gmail dot com --- Comment #2 from Sergey Semushin --- Shouldn't it actually use an array for all enum types having 1-byte size including std::byte?
[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86899 Sergey Semushin changed: What|Removed |Added CC||Predelnik at gmail dot com --- Comment #5 from Sergey Semushin --- Had the same issue where the only dead code was leftover break in a switch case after return. Reasons are probably exactly the same but maybe in this form this issue will arise more often.
[Bug c++/81678] New: Variadic template parameters containing pointer to member function fail to be parsed unless name of the parameter is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81678
Bug ID: 81678
Summary: Variadic template parameters containing pointer to
member function fail to be parsed unless name of the
parameter is specified
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
The following example is not compiling:
template
void f (void (T::*...)())
{
}
struct C
{
void f (){}
};
int main ()
{
f (&C::f);
}
Replacing
void f (void (T::*...)())
with
void f (void (T::*...a)())
makes it compile.
Think it should compile in both cases.
[Bug c++/79504] New: Mix of perfect forwarding and reference qualifier leads to recursive template instantiation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504
Bug ID: 79504
Summary: Mix of perfect forwarding and reference qualifier
leads to recursive template instantiation.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
The following example seems correct to me and is accepted by msvc/clang but gcc
rejects it starting from version 4.8 up to current day versions with "template
instantiation depth exceeds maximum of 900". Removing trailing type helps, so
it's gotta be problem with f in trailing type being the wrong one I guess.
#include
struct A
{
void f () & {}
template auto f (Args &&... args) && -> decltype
(std::move (this->f (std::forward (args)...)))
{
return std::move (this->f (std::forward (args)...));
}
};
int main (){
A p;
p.f ();
}
[Bug c++/66243] New: enum class value is allowed to be initialized by value from other enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66243
Bug ID: 66243
Summary: enum class value is allowed to be initialized by value
from other enum class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
>From my understanding enum class values could be initialized by integer
constant expression (and thus by its own already defined values since they are
implicitly convertible to int in its scope). However g++ compiles the following
code where this value is taken from other completely unrelated enum class and
thus shouldn't be implicitly convertible to integer type in its scope.
enum class A
{
X
};
enum class B
{
X = A::X,
};
int main()
{
}
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Sergey Semushin changed:
What|Removed |Added
CC||Predelnik at gmail dot com
--- Comment #8 from Sergey Semushin ---
Encountered this warning and it makes me wonder why there is no warning for
naming variable inside some namespace with the same name as a class in outer
namespace, like:
struct C {};
namespace D
{
int C;
}
This case is very similar to enum class one and I believe it's a lot easier to
somehow be confused here due to shadowing however no warning with Wshadow is
issued this case. Personally I would prefer to not receive warning in both
cases.
