public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jason Merrill <jason@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [C++ PATCH] Disable VLA initialization? (PR sanitizer/79993)
Date: Thu, 30 Mar 2017 22:00:00 -0000	[thread overview]
Message-ID: <2ed0c9a3-374f-e703-9d11-535be672518c@gmail.com> (raw)
In-Reply-To: <20170330202411.GL17461@tucnak>

On 03/30/2017 02:24 PM, Jakub Jelinek wrote:
> On Thu, Mar 30, 2017 at 10:21:09AM -0600, Martin Sebor wrote:
>> 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
>
> The Asan ICE can be easily worked around, the reason I don't want to do that
> is that this is the second time this broke something; the FE should
> not pass a VLA static constant (STRING_CST in this case) to the middle-end,
> VLA objects can be by definition only automatic variables or something
> on the heap, never in the data/rodata sections.
> Plus, while for VLA initialized from arrays etc. we copy the initializer
> and zero initialize the rest, for VLA initialization by STRING_CST we
> just copy over the STRING_CST and the rest is uninitialized.

I agree that's a bug, one that should be fixed, but ion my view
it's not serious enough to justify disabling the feature altogether.

If every feature with a bug in it or that happens to trigger an ICE
with some combination of command line options had to be disabled
there wouldn't be much left.

As I said, a patch that fixes this exists.  I ran out of time to
resubmit it for GCC 7 but I plan to do it for GCC 8.  It be quite
unfriendly to users to have GCC 7 reject working code that's
accepted by GCC 6 only to have GCC 8 accept it again.

I know you have concerns about the runtime costs of the patch
and I'm willing to listen and work with you to minimize the
performance impact.

Martin

      reply	other threads:[~2017-03-30 21:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 19:37 Jakub Jelinek
2017-03-30 17:15 ` Martin Sebor
2017-03-30 20:30   ` Jakub Jelinek
2017-03-30 22:00     ` Martin Sebor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ed0c9a3-374f-e703-9d11-535be672518c@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).