[Bug libstdc++/86164] std::regex crashes when matching long lines

[nyh at math dot technion.ac.il via Gcc-bugs]

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

--- Comment #15 from Nadav Har'El  ---
More than 5 years later, more and more projects are discovering this bug the
hard way, and moving from std::regex to boost::regex which doesn't have this
bug - boost::regex defaults to BOOST_REGEX_NON_RECURSIVE mode, which uses a
stack on the heap instead of recursion (but I don't know if the specific
examples shown the various duplicates all need this stack in practice, for
example it's unfortunate if matching " *" needs to copy the entire input string
in a stack). The latest example of this exodus is
https://github.com/scylladb/scylladb/pull/13452. 
So I think it's about time this issue is solved. Maybe even the Boost
implementation can studied for inspiration and implementation ideas?

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

[nyh at math dot technion.ac.il via Gcc-bugs]

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

--- Comment #21 from Nadav Har'El  ---
This old problem has become a real problem in gcc 12 with a real effect on
incorrect code generation, where code that copies an object was incorrectly
"optimized" to use __builtin_memcpy() instead of __builtin_memmove() even
though the source and destination objects may overlap - and it turns out that
__builtin_memcpy() may produce incorrect results for overlapping addresses.

This bug was discovered in the OSv project
https://github.com/cloudius-systems/osv/issues/1212 with code that doesn't
(obviously) call __builtin_memcpy() directly, but rather had a 27-character
type being copied and the compiler implemented this copy with a call to
__builtin_memcpy(). Here is an example of code which generates the wrong
results (note the missing "c" in the result and unexpectedly doubled "g"):

#include 
int main(){
char buf[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
struct [[gnu::packed]] data {
char x[27];
};
void *p0 = buf;
void *p1 = [1];
*static_cast(p0) = *static_cast(p1);
printf("%s", buf);
}

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

[nyh at math dot technion.ac.il via Gcc-bugs]

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

--- Comment #2 from Nadav Har'El  ---
Thanks. Interesting. So __builtin_memcpy() is simply not supposed to work
correctly for overlapping areas? I now realize that according to memcpy(3)
documentation, memcpy() is also not guaranteed to work correctly in this case
(and you should use memmove() in this case), but in practice it does work
correctly when copying a higher address to a lower address.

[Bug c/108296] New: __builtin_memcpy generating wrong code in some cases

[nyh at math dot technion.ac.il via Gcc-bugs]

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

Bug ID: 108296
   Summary: __builtin_memcpy generating wrong code in some cases
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

The following trivial code, copying a string over itself moved by one byte,
shows wrong results for __builtin_memcpy() on gcc 12.2.1:

#include 
int main(){
char bufa[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
char bufb[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
memcpy(bufa, bufa+1, 27);
printf("  memcpy: %s\n", bufa);
__builtin_memcpy(bufb, bufb+1, 27);
printf("__builtin_memcpy: %s\n", bufb);
}

As you can see running it, memcpy() returned the right result,
123456789abcdefghijklmnopqrrstuvwxyz (the first 27 characters shifted back, so
"r" is double in the response), but __builtin_memcpy() returned the *wrong*
result - 123456789abdefgghijklmnopqrrstuvwxyz (the "c" character disappeared
and the "g" is  also doubled).


This bug was discovered in the OSv project
https://github.com/cloudius-systems/osv/issues/1212 with code that doesn't
(obviously) call __builtin_memcpy() directly, but rather had a 27-character
type being copied and the compiler implemented this copy with a call to
__builtin_memcpy(). The original miscompiling code in OSv  was something like
the following:

#include 
int main(){
char buf[128] = "0123456789abcdefghijklmnopqrstuvwxyz";
struct [[gnu::packed]] data {
char x[27];
};
void *p0 = buf;
void *p1 = [1];
*static_cast(p0) = *static_cast(p1);
printf("%s", buf);
}

This appears to be a regression - this code did not miscompile in earlier gcc
releases.

[Bug c/106087] Segmentation fault in GIMPLE pass: ccp

[nyh at math dot technion.ac.il via Gcc-bugs]

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

--- Comment #1 from Nadav Har'El  ---
Created attachment 53199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53199=edit
preprocessed source file which gcc saved for reporting the crash (compressed
because of bugzilla's attachment length limit)

[Bug c/106087] New: Segmentation fault in GIMPLE pass: ccp

[nyh at math dot technion.ac.il via Gcc-bugs]

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

Bug ID: 106087
   Summary: Segmentation fault in GIMPLE pass: ccp
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

When building the attached file, part of the open-source OSv project, in gcc
12.1.1 (on Fedora 36), I get:


during GIMPLE pass: ccp
bsd/sys/dev/hyperv/vmbus/hyperv.cc: In function ‘bool hyperv_identify()’:
bsd/sys/dev/hyperv/vmbus/hyperv.cc:117:1: internal compiler error: Segmentation
fault
  117 | hyperv_identify()
  | ^~~
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccCg8LNL.out file, please attach this to
your bugreport.

The preprocessed source file is attached.

I discovered that removing the two static variables hyperv_pm_features and
hyperv_features3 makes the compilation succeed. These two variables are static,
and are only set by the function which failed compilation and never read
anywhere else in the source file, so these variables are not needed. So I would
have accepted a warning about them being unused - but not a compiler crash.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

[nyh at math dot technion.ac.il via Gcc-bugs]

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

Nadav Har'El  changed:

   What|Removed |Added

 CC||nyh at math dot technion.ac.il

--- Comment #27 from Nadav Har'El  ---
I think this problem still exists at least in some form, and should be
reopened. It just hit the Seastar project, with gcc 11.1.1 -
https://github.com/scylladb/seastar/issues/914.

The problem there is that it uses C-style callbacks (of the c-ares library)
that cannot be modified; The callback gets a void* argument. We pass a C++'s
object's address into this void*, and then inside the callback function itself,
cast the void* back (using reinterpret_cast) to the object pointer - and then
attempt to run methods of this pointer. Here is where gcc 11.1.1. warns us that
this pointer may be a null (the message erroneously says "is a null") -
although I know for a fact it cannot be a null, and sadly even adding an
assert(p) to tell the compiler I'm sure it is not a null - doesn't help.