[PATCH] Handle not explicitly zero terminated strings in merge sections

[Bernd Edlinger]

Hi!


This patch is inspired by Olivier's feedback to my previous patch on the
zero-termination of Ada STRING_CST.

The idea is that strings that do not have embedded nul characters _and_
do not happen to be zero-terminated in the DECL_UNIT_SIZE, are currently
not in the merge string sections.  To be in the merge string section
they need a terminating nul character, that gets written directly
in varasm while assembling the string constant.  This patch uses
the new string properties that my previous patch series implements,
and is based on the other patches here:

[PATCH] Check the STRING_CSTs in varasm.c
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00331.html

[PATCH] Handle overlength strings in the C FE
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00142.html

[PATCH] Handle overlength strings in C++ FE
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00045.html
Approved: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00105.html

[PATCH] Make GO string literals properly NUL terminated
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01931.html

[PATCH] [Ada] Make middle-end string literals NUL terminated
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01929.html


The existing test case gcc.dg/merge-all-constants-1.c
contains two overlength strings that get now stripped down
by the C FE, and look in the middle end exactly like normal
Ada, Fortran or Go strings.  And get now allocated
in the merge.str section, unless they have an embedded
nul character, which I changed to make the test pass again.

Olivier, could you add test cases from the Ada side to this?


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk (after all pre-condition patches
are approved/committed)?


Thanks
Bernd.