public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Marek Polacek <polacek@redhat.com>,
	 GCC Patches <gcc-patches@gcc.gnu.org>,
	Jason Merrill <jason@redhat.com>
Subject: Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function)
Date: Wed, 27 Jan 2016 03:58:00 -0000	[thread overview]
Message-ID: <56A8404E.9030005@gmail.com> (raw)
In-Reply-To: <20160126230246.GO25528@redhat.com>

On 01/26/2016 04:02 PM, Marek Polacek wrote:
> The (invalid) testcase was causing an ICE because we were passing the result
> of array_type_nelts_top immediately into tree_int_cst_lt, but for VLAs, the
> result doesn't have to be a constant.  Fixed by evaluating the bound of the
> array so that we're able to give a proper out-of-bounds diagnostics.  And the
> VERIFY_CONSTANT should ensure that if the array bound couldn't be reduced to
> a constant, we bail out rather than evoke an ICE.

Wow, you are quick! :)

I wonder if it might be better to instead reject VLAs in constexpr
functions altogether.  Not because they're not in C++, but because
C (or gcc) doesn't allow them to be initialized (and so accepting
an initialized VLA is a g++ extension of an extension), and
because in constexpr functions they are rejected without
initialization just like other uninitialized variables.

FWIW, it seems to me the fewer extensions we support the less risk
of something going wrong because of unforeseen interactions with
other features.

Martin

  reply	other threads:[~2016-01-27  3:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 23:02 Marek Polacek
2016-01-27  3:58 ` Martin Sebor [this message]
2016-01-27 11:20   ` Marek Polacek
2016-01-27 16:52     ` Martin Sebor
2016-01-27 21:08       ` Jason Merrill
2016-01-28 22:27       ` Marek Polacek
2016-01-29  3:29         ` Martin Sebor
2016-01-27 14:08 ` Jason Merrill
2016-01-27 14:11   ` Marek Polacek

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=56A8404E.9030005@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=polacek@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).