https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #13 from David Binderman ---
(In reply to Jonathan Wakely from comment #12)
> Might as well just start the right version and skip that first approximation.
It sounds to me like you are somewhat keen to implement.
Feel free to go righ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #12 from Jonathan Wakely ---
A first approximation that is implemented in the wrong part of the compiler,
using the wrong logic, giving the wrong answers, is not a step in the right
direction because it would need to be completely red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #11 from Jonathan Wakely ---
I would expect no false positives for a warning like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #10 from David Binderman ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to David Binderman from comment #8)
> > My opinion is that a first approximation at implementation in gcc would
> > merely look for C++ member func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #9 from Jonathan Wakely ---
(In reply to David Binderman from comment #8)
> My opinion is that a first approximation at implementation in gcc would
> merely look for C++ member functions that are return statements only.
> More fancy t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #8 from David Binderman ---
(In reply to Jonathan Wakely from comment #7)
> struct indirect_cmp {
> static int counter;
> bool operator()(const X* l, const X* r) {
> ++counter;
> return *l < *r;
> }
> };
>
> int indirec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Also useful would be to warn for members that don't access any state at all:
>
> struct indirect_cmp {
> bool operator()(const X* l, const X* r) { return *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #6 from Martin Sebor ---
You're right, there is a substantial difference between attributes const/pure
and constness in the C/C++ sense. A warning that detects missing const on
member functions (i.e., this request) is implementable i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #5 from David Binderman ---
(In reply to Martin Sebor from comment #3)
> There is a warning like that in the middle-end: -Wsuggest-attribute=pure.
Whether a function is pure is a slightly different thing
to whether it is a C++ const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
Martin Sebor changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
--- Comment #3 from Martin Sebor ---
There is a warning like that in the middle-end: -Wsuggest-attribute=pure.
Unfortunately, it's only good for functions that are actually emitted (i.e.,
not for C++ inline functions).
$ cat t.C && gcc -O2 -S -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-05-11 00:00:00 |2017-11-22
--- Comment #2 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80711
Martin Sebor changed:
What|Removed |Added
Severity|normal |enhancement
14 matches
Mail list logo
