[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Nikolay Orliuk changed:
What|Removed |Added
CC||virkony at gmail dot com
--- Comment #4 from Nikolay Orliuk ---
Just curious if this code works good with return value optimization like:
static inline T conditional_update(T&& src, bool flag) {
if (flag) {
return T{};
} else {
return std::move(src);
}
}
T a;
a = conditional_update(a, true);
a = conditional_update(a, false);
Is it going to produce warning after inlining and propagating constants?..
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
--- Comment #9 from Nikolay Orliuk ---
Yes. Return value optimization blocked by abusing std::move also close. Somehow
I had feeling that I saw something similar from gcc in pre-C++11 times.
Regarding sample:
struct X {
X() { }
X(const X&) { }
X(const X&&) { }
};
const X x;
const X y = std::move(x);
It shouldn't warn because std::move is effective here and makes choice between
default (const X&) and (const X&&) overloads. I.e. we are not ignoring the fact
that it is rvalue.
As I stated initially I agree that most likely templates will cause false
triggering. Like for other warnings (ex. -Wduplicated-branches ).
The main point here was to identify places that potentially migrated
incompletely. Kinda temporary flag.
Trigger rule might be: cast to rvalue for overloads one of which have slightly
different qualifiers combinations (e.g. const vs non-const).
That should a bit reduce chances of false trigerring compared to "whenever we
ignore rvalue".
If someone will want more noise they can request adding -Wsuggest-move-overload
to supported flags :)
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
--- Comment #2 from Nikolay Orliuk ---
Sure,
struct Value {
Value();
Value(const Value&);
Value(Value&&);
};
struct Frame {
Value value; // previously mutable
};
Frame top;
const Frame& x = top;
Value y = std::move(x.value);
https://godbolt.org/g/v24FfQ
Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.
Such warning will help to identify places which become ineffecient after
changing constness of something.
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
--- Comment #3 from Nikolay Orliuk ---
Sure,
struct Value {
Value();
Value(const Value&);
Value(Value&&);
};
struct Frame {
Value value; // previously mutable
};
Frame top;
const Frame& x = top;
Value y = std::move(x.value);
Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.
Such warning will help to identify places which become ineffecient after
changing constness of something.
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
--- Comment #4 from Nikolay Orliuk ---
Hello
Sure,
struct Value {
Value();
Value(const Value&);
Value(Value&&);
};
struct Frame {
Value value; // previously mutable
};
Frame top;
const Frame& x = top;
Value y = std::move(x.value);
https://godbolt.org/g/v24FfQ
Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.
Such warning will help to identify places which become ineffecient after
changing constness of something.
P.S. By some reason I were not able to leave comment in Bugzilla and got
message "User account creation filtered due to spam." though I were logged
in.
Thank you,
Mykola
On Thu, Aug 24, 2017 at 7:40 AM egallager at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
>
> Eric Gallager changed:
>
>What|Removed |Added
>
>
>Keywords||diagnostic
> Status|UNCONFIRMED |WAITING
>Last reconfirmed||2017-08-24
> CC||egallager at gcc dot
> gnu.org
> Ever confirmed|0 |1
>
> --- Comment #1 from Eric Gallager ---
> Could you please provide a complete self-contained example? The snippet you
> posted looks like it's missing some declarations:
>
> $ /usr/local/bin/g++ -c 67906.cc
> 67906.cc:1:7: error: ‘Frame’ does not name a type
> const Frame& x = stack.top();
>^
> 67906.cc:2:1: error: ‘Value’ does not name a type
> Value y = std::move(x.value); // x.value - non-mutable
> ^
> $
>
> Anyways, bug 81159 is related, but that's about a different misuse of
> std::move, so I'll keep the 2 separate.
>
> Oh, and also "-Wno-effect" would probably be a bad name for the option,
> since
> "-Wno-" is reserved for negative versions of warnings. i.e., is
> "-Wno-effect"
> the negative of "-Weffect"? That seems wrong. Or is it already in the
> positive,
> in which case the negative is "-Wno-no-effect"? That would seem redundant.
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug c++/59813] New: tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
Bug ID: 59813
Summary: tail-call elimintation didn't fired with left-shift of
char to cout
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: virkony at gmail dot com
#include
using namespace std;
void foo()
{
cout << "x" << endl; // ok
cout << 'x' << endl; // kills tail-call elimination in gcc 4.8.2
foo();
}
int main() { foo(); return 0; }
// core-dups by long stack while in 4.7.3 works as expected (infinite loop)
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
--- Comment #1 from Nikolay Orliuk ---
In 4.7.3 that code works, but changing it to
void foo()
{
cout << "x" << endl; // ok
cout << 'x' << endl; // kills tail-call elimination in gcc 4.8.2
struct {} bar; // kills tail-call elimination in 4.7.3
foo();
}
Removing either "bar" or 'x' results in normal infinite loop.
In 4.5.4 this works fine as is.
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #2 from Nikolay Orliuk --- My 4.5.4 built without graphite support. Both 4.7.3 and 4.8.2 built with cloog 0.17.0 and isl 0.11.2
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
--- Comment #4 from Nikolay Orliuk ---
Andrew Pinski, as long as address of variable isn't taken out of scope of
function that is being tail-call optimized there is no need to worry about it
and it is safe to optimize. Am I wrong?
If stdc++ lib contains code like:
ostream &operator<<(ostream &os, char x)
{ os.__escape = &x; }
That's probably wrong and should be fixed.
Tried to override with:
ostream &operator<<(ostream &os, char x)
{ cout.put(x); return os; } // works on all 4.5.4, 4.7.3 and 4.8.2
ostream &operator<<(ostream &os, char x)
{ cout.write(&x, 1); return os; } // fails even without "bar" for 4.7.3 and
4.8.2
Note that strange behaviour of 4.7.3. Is that means that adding "bar" fires
inlining?..
[Bug c++/67906] New: Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 Bug ID: 67906 Summary: Missing warning about std::move without effect Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: virkony at gmail dot com Target Milestone: --- It would be nice to have something like -Wno-effect which will issue warnings on usage of std::move for objects that cannot be moved. See also http://stackoverflow.com/q/28595117/230744 I assume that it may require introducing differentiation between explicit-rvalue (through std::move()/cast) and implicit-rvalue. This may save from errors like: ``` const Frame& x = stack.top(); Value y = std::move(x.value); // x.value - non-mutable ``` Though there might be a false-positives in template functions or when developer expects that in future function will have move overload for that argument.
