[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667

--- Comment #64 from Patrick J. LoPresti  ---
The C (and POSIX) standards have had "restrict" on the arguments to memcpy()
since C99. So calling it with overlapping arguments is undefined behavior and
always has been.

This bug should be trivial to fix by checking for self-assignment before
calling memcpy(). Doesn't GCC inline the assignments for small objects anyway?

I still have no idea why this is even controversial.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642

--- Comment #17 from Patrick J. LoPresti  ---
Are all of the "duplicate" bugs also fixed by this change?

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667

--- Comment #29 from Patrick J. LoPresti  ---
(In reply to Jakub Jelinek from comment #27)
> 
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.

The very existence of (and interest in) this bug report means it is obviously
not "a theoretical only problem".

And of course Rich Felker is correct that the cost of the obvious fix is
trivial and not remotely "severe".

But the bottom line is that GCC is emitting library calls that invoke undefined
behavior. At a minimum, GCC should document this non-standard requirement on
its runtime environment. Has anyone bothered to do that? Why not?

[Bug c++/109671] Spurious dangling reference warning in GCC 13

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671

--- Comment #3 from Patrick J. LoPresti  ---
(In reply to Andrew Pinski from comment #1)
> There is no way for GCC to know that get_foo_by_name does not store the
> argument into what is returned so it warns about this case ...

To summarize:

GCC is warning because it does not and cannot know whether I am managing object
lifetimes correctly.

The only way to silence the warning is to modify my code to make it uglier,
into a form where GCC still does not and cannot know whether I am managing
lifetimes correctly.

So is this a valid bug report, or not?

[Bug c++/109671] Spurious dangling reference warning in GCC 13

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671

--- Comment #2 from Patrick J. LoPresti  ---
Um... OK...

So I have to "correct" my code like so:

const Foo (bool x)
{
  const std::string s = (x ? "x" : "y");
  const Foo  = get_foo_by_name(s);
  return f;
}

But if get_foo_by_name() has the problem GCC is worried about, this does not
even fix it.

This warning seems silly to me. "I cannot tell if you are managing lifetimes
properly, so I will just recommend you do not use temporaries"?

Const references have always bound to temporaries. This warning seems to be
discouraging that (?)

[Bug c++/109671] New: Spurious dangling reference warning in GCC 13

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671

Bug ID: 109671
   Summary: Spurious dangling reference warning in GCC 13
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com
  Target Milestone: ---

#include 

struct Foo;

extern Foo _foo_by_name(const std::string );

const Foo (bool x)
{
  const Foo  = get_foo_by_name(x ? "x" : "y");
  return f;
}

---

Compile with "-O2 -Wall" to get the incorrect warning:

: In function 'const Foo& bug(bool)':
:9:14: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
9 |   const Foo  = get_foo_by_name(x ? "x" : "y");
  |  ^
:9:33: note: the temporary was destroyed at the end of the full
expression 'get_foo_by_name(std::__cxx11::basic_string(((const char*)(x ?
"x" : "y")), std::allocator()))'
9 |   const Foo  = get_foo_by_name(x ? "x" : "y");
  |  ~~~^~~

--

Godbolt: https://godbolt.org/z/cn4W7ohGb

The code is fine. (And no other compiler warns about this, including earlier
GCC versions.)

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[lopresti at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667

--- Comment #22 from Patrick J. LoPresti  ---
I disagree that bug 108296 is a duplicate. That bug requires code that, at
least arguably, invokes undefined behavior. See e.g.
https://stackoverflow.com/q/7292862/ and https://stackoverflow.com/q/61070828/.

This bug is about clearly valid C++ code (object self-assignment) for which GCC
emits clearly invalid calls to memcpy() (with dest == src).

Now, I suspect what Andrew is thinking is that both of these bugs could be
resolved by invoking memmove() instead of memcpy(). That seems like a
reasonable idea to me, since small assignments get inlined and large
assignments can amortize the overhead.

But this bug could also be resolved in other ways, a few of which have been
suggested in these comments.