On 7/28/20 9:00 AM, Richard Biener via Gcc-patches wrote:
On Mon, Jul 27, 2020 at 10:49 PM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On Mon, Jul 27, 2020 at 09:53:31AM -0600, Martin Sebor via Gcc-patches wrote:
Return a pointer P to a NUL-terminated string containing
the sequence of bytes corresponding to the representation
of the object referred to by SRC (or a subsequence of such
bytes within it if SRC is a reference to an initialized
constant array plus some constant offset).
I.e., c_getstr returns a STRING_CST for arbitrary non-string
constants. This enables optimizations like the by-pieces
expansion of calls to raw memory functions like memcpy, or
the folding of other raw memory calls like memchr with non-
string arguments.
c_getstr relies on string_constant for that. Restricting
the latter function to just character types prevents these
optimizations for zero-initialized constants of other types.
A test case that shows the difference to the by-pieces
expansion goes something like this:
Having STRING_CST in the compiler with arbitrary array type is IMHO a very
bad idea, so if you want something like that, you should come up with a
different representation for that, not STRING_CSTs.
Because most of the compiler assumes STRING_CSTs are what it says, string
literals where elements are some kind of characters, don't have to be
narrow, but better should be integral.
Maybe returning a CONSTRUCTOR with no elements with the right type is a
better idea for that, that in the compiler stands for zero initialized
aggregate.
It's also a much shorter representation (that also works for strings, btw)
if it is all about all-zero "constants".
Richard.
Jakub
Based on the upcoming discussion, I decided to backport my current fix to
releases/gcc-10
branch in order to fix the problematic ICE in chromium. I'm ready to backport
whatever
Martin comes up with.
Martin
