On 03/29/2017 01:31 PM, Jakub Jelinek wrote:
Hi!
GCC 4.8 and earlier didn't allow in C++ initialization of VLA and
C doesn't allow it in any GCC release. This has changed when the
support for C++1y VLA has been added, then reverted, but apparently
only partially.
The question is, do we want to support VLA initialization, if yes,
with what exact semantics (in that case we need to fix up initialization
from STRING_CST which is broken right now).
The following patch is the variant that disables it (bootstrapped/regtested
on x86_64-linux and i686-linux).
Looking at what is emitted for initialization from non-STRING_CSTs,
it seems that we consider UB if the VLA is shorter than the initializer
array, and if it is longer, we somehow initialize the rest (dunno what
exact C++ initialization kind, there are some testcases
with ctors in the list below; for PODs zero initialization).
So, if we want to keep it and just fix STRING_CST initialization,
shall we emit memcpy from the array followed by whatever we emit right now
for the excess elements (for initialization from STRING_CST, can it ever
be anything but zero initialization? If not, then memset would do the job).
I already chimed in on the bug report but just for the record,
my view is that it would be preferable to continue to allow VLAs
to be initialized as long as the excess initialization isn't
allowed to trash the stack as it is now (bug 69517). The patch
for that was committed into GCC 6 but had to be reverted due to
interfering with Java's own implementation of exception). With
Java removed I'd like to resubmit the patch in GCC 8.
I don't think rejecting all VLA initialization just to avoid
an Asan ICE with string literals is a good way to solve the
problem. For one, it will break working programs that rely on
what is currently accepted by GCC and for which it emits valid
code. Longer term, users will likely come up with other ways
to initialize their VLAs that may be even harder (or slower)
for GCC to detect bugs in that the plain initialization.
Martin
