[Bug c++/96278] New: three-way comparison operator comparison to 0: spurious nullptr warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96278
Bug ID: 96278
Summary: three-way comparison operator comparison to 0:
spurious nullptr warning
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
Bug in g++ 10.1.0 with libstdc++
compile following program doing `g++-10 -std=c++20
-Wzero-as-null-pointer-constant`
#include
#include
int main () {
bool result { (1 <=> 2) < 0 };
std::cout << (result ? "Yes" : "No") << std::endl;
}
produces the error:
foo.cc:5:27: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
Also compiler-synthesized comparisons will generate this which is especially
confusing as they can happen when calling a library function that needs the '<'
operator.
the exact version of GCC: 10.1.0
the system type: MacOS 10.15 (and Ubuntu 18.4 LTS using apt-get of gcc 10)
the options given when GCC was configured/built: (homebrew version): Configured
with: ../configure --build=x86_64-apple-darwin19
--prefix=/usr/local/Cellar/gcc/10.1.0
--libdir=/usr/local/Cellar/gcc/10.1.0/lib/gcc/10 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-10 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 10.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
SED=/usr/bin/sed
[Bug c++/96278] three-way comparison operator comparison to 0: spurious nullptr warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96278 --- Comment #2 from DV Henkel-Wallace --- (In reply to Andrew Pinski from comment #1) > I think this is a dup of bug 95242. Could be: I'm not sure if Jason's change applies only to synthesized comparators or not (that was the case described in 95242 and was the second case I mentioned). I hope it is already fixed. However the test case I submitted is the user-supplied 0 literal per the standard the standard, not a synthetic case. So might or might not be; I no longer grok the gcc internals so can't tell myself. Thanks -d
[Bug c++/96489] New: Three way comparison operator failure to synthesize traditional comparitors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489
Bug ID: 96489
Summary: Three way comparison operator failure to synthesize
traditional comparitors
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
User-defined <=> doesn't generate == or != though user-defined operator== and
operator<=> = default do.
/usr/local/opt/gcc/bin/g++-10 -std=c++20 foo.cc && ./a.out
foo.cc: In function 'int main()':
foo.cc:21:9: error: no match for 'operator!=' (operand types are 'foo' and
'foo')
21 | if (a != b) std::cout << "not ";
| ~ ^~ ~
| ||
| foo foo
foo.cc:25:11: error: no match for 'operator==' (operand types are 'foo' and
'foo')
25 | if (!(a == c)) std::cout << "not ";
| ~ ^~ ~
| ||
| foo foo
#include
struct foo {
int content;
foo(int x) : content { x } {}
// works: auto operator <=> (foo const& rhs) const = default;
// works: auto operator == (foo const& rhs) const { return content ==
rhs.content; }
// fails:
auto operator <=> (foo const& rhs) const { return content <=>
rhs.content; }
};
int main() {
foo a { 1 };
foo b { 2 };
foo c { 1 };
if (a != b) std::cout << "not ";
std::cout << "equal" << std::endl;
if (!(a == c)) std::cout << "not ";
std::cout << "equal" << std::endl;
return 0;
Result:
/usr/local/opt/gcc/bin/g++-10 -std=c++20 foo.cc && ./a.out
foo.cc: In function 'int main()':
foo.cc:21:9: error: no match for 'operator!=' (operand types are 'foo' and
'foo')
21 | if (a != b) std::cout << "not ";
| ~ ^~ ~
| ||
| foo foo
foo.cc:25:11: error: no match for 'operator==' (operand types are 'foo' and
'foo')
25 | if (!(a == c)) std::cout << "not ";
| ~ ^~ ~
| ||
| foo foo
[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489 --- Comment #2 from DV Henkel-Wallace --- I don't think this should be marked as resolved. The bug is not the case you cited which indeed works properly as specified. The bug is that comparators are not being synthesized when the a *user supplied* operator<=> is defined. I believe this case is [class.spaceship] case (1.1). Although that case does reference [class.compare.default], it talks about the spaceship operator being "usable" which is defined, via clause (3), to have a defined binary operator of appropriate types -- _not_ claiming that only the `= default` case applies. More pragmatically the user will expect that their explicit definition of <=> will result in unspecified comparisons being synthesized. Else why define it in the first place?
[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489 --- Comment #5 from DV Henkel-Wallace --- (In reply to Jonathan Wakely from comment #4) > I believe the rationale for this is that if your <=> can't be defaulted, > then it must be doing something special, and synthesizing == from it is not > necessarily safe. The thing is: properly written user defined operator <=> is supposed to to be "correct" (whatever that would mean!) for all of the < 0, = 0, and > 0 cases. It doesn't make sense to presume that a user defined <=> would only apply to the < and > cases -- in fact how could it otherwise synthesize <= and => ? (More jocularly it's not `operator <>` -- would we call that the submarine operator?) In fact I just changed my test case to use `((a <=> b) != 0)` and it did what I expected. > Clang agrees with GCC FWIW. Yes, reported it to them too :-(
[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489 --- Comment #7 from DV Henkel-Wallace --- Thanks. That is clear. BTW FWIW, defining <=> myself and then defining == default does appear to do what I want (i.e. I don't have to use. = default with both operators). I saw that cppreference claims that `== default` will do `<=> < 0` -- though I know that site isn't authoritative, merely close to authorotative. Sorry about reporting a non-bug and thanks for your patience in your response.
[Bug c++/83280] New: gcc doesn't realize a returning value from complete switch(enum...) does return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83280
Bug ID: 83280
Summary: gcc doesn't realize a returning value from complete
switch(enum...) does return a value
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
Given this file:
===
enum class e { a, b, c};
int converter (e val);
int converter (e val) {
switch (val) {
case e::a: return 0;
case e::b: return 1;
case e::c: return 2;
}
}
===
g++ 7.2 doesn't realize this function always returns correctly:
$ g++-7 -Wswitch -Wreturn-type -std=c++11 -c enum-problem.cc
enum-problem.cc: In function 'int converter(e)':
enum-problem.cc:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
$
