https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #7 from m.cencora at gmail dot com ---
This seems to be fixed in gcc 12.3 and gcc 13+
Can we close this?
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code fails to compile on any gcc version with any selected language
version. Works with clang.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #1 from m.cencora at gmail dot com ---
Fixed sample (a typo in else branch of WORKAROUND2):
struct no_copy
{
no_copy() = default;
no_copy(const no_copy&) = delete;
no_copy(no_copy&&);
no_copy&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #2 from m.cencora at gmail dot com ---
> When invoking the conversion operator the problem does not occur.
When invoking the conversion operator *explicitly* the problem does not occur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #4 from m.cencora at gmail dot com ---
This also might be a just another symptom of the same root cause:
struct bar
{
bar() = default;
bar(const bar&);
bar(bar&&);
bar& operator=(const bar&);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #5 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
This one is actually a regression (worked on gcc 8.3 and older)
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code when compiled on any gcc version (checked all available on
godbolt since gcc-7) triggers conversion warnings.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
--- Comment #2 from m.cencora at gmail dot com ---
So I guess this falls into the "confusing overload resolution for user-defined
conversion" but I fail to see what can be confusing here.
createInt() returns prvalue, so later it binds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #11 from m.cencora at gmail dot com ---
This is surprising to say the least because apparently for following code
(where both conversion operators return same type) the compiler somehow
correctly chooses && qualified
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat repeated_using.cpp
module;
namespace std
{
void make_error_code();
}
export module std;
export namespace std
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat op_new.cpp
module;
void* operator new(unsigned long, void*);
namespace std
{
template
auto construct_at(_Tp*) -> decltype(::new((void*)0) _Tp())
{
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115445
--- Comment #1 from m.cencora at gmail dot com ---
Works fine on gcc-14 and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #15 from m.cencora at gmail dot com ---
Thanks!
Unfortunately it seems that your changes broke reexporting of types declared in
other module. It works fine on gcc-14.
$ cat base.cpp
module;
#include
export module base;
export
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat base.cpp
module;
#include
export module base;
export
{
using ::int8_t;
}
export namespac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #1 from m.cencora at gmail dot com ---
Also this is specific to types exported from GMF, if type is declared directly
in named module it works fine, i.e.
$ cat base.cpp
export module base;
export
{
using int8_t = signed char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #2 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #1)
> Also this is specific to types exported from GMF, if type is declared
> directly in named module it works fine, i.e.
>
> $ cat base.c
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
It seems like the deprecation warning is kept even if triggered due to failed
substitution in context of class partial speciali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #3 from m.cencora at gmail dot com ---
I think it should be marked rejects-valid because it makes valid program
ill-formed if compiled with -Werror. The problematic diagnostic is user-defined
but in code that is never reached, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #5 from m.cencora at gmail dot com ---
> I'd say that warning is not expected, because user's code didn't (directly
> or indirectly) call the deprecated constructor.
Or to state it differently: user calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #6 from m.cencora at gmail dot com ---
Another argument for not showing the deprecation is that if I change:
string a;
to
const string a;
I don't get any deprecation warnings, but only for gcc-11+.
This means that int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am not sure this is related to SFINAE though.
> >
> > Rather it is in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #8 from m.cencora at gmail dot com ---
(In reply to Patrick Palka from comment #7)
> Substituting U=string into overload_set::type during
> overload resolution certainly has the side effect of instantiating that
> class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120160
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
101 - 125 of 125 matches
Mail list logo
