public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
Date: Mon, 21 Mar 2022 17:22:52 +0000	[thread overview]
Message-ID: <bug-104970-4-VgEeioUh2a@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104970-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Incidentally, __builtin_dynamic_object_size returns the size of a VLA parameter
in both mininum and maximum modes.  In f0 below, the size of the A array is at
least N bytes but it could be more, so based on my reading of the manual, it
seems like f0 is actually supposed return -1 (f1 looks fine).  If my reading is
correct that would seem unfortunate because it would basically makes BDOS
ineffective for _FORTIFY_SOURCE of VLA parameters.

long f0 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 0);   // folded to n, should be -1?
(Clang folds to -1)
}

long f1 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 1);   // folded to n (Clang folds to
-1)
}

Even more unfortunate seems that that without the [static] it's not undefined
to pass an array with fewer elements than the VLA bound indicates to a function
like f0 of f1.  GCC BDOS doesn't seem to consider the [static] notation and
folds the result the same way either way.  So while well-written code will
benefit from the stricter runtime checking made possible by the tighter bound,
it will cause aborts for poorly written code that's strictly valid.  If I'm
right about this, adding a permissive mode to BDOS to accommodate the poorly
written but valid code might be a way out.

There are cases when __builtin_dynamic_object_size could put the VLA bounds to
use, although I suspect they don't mater for _FORTIFY_SOURCE; if they should
matter, the brute force pr97172 fix might need to be revisited and the bounds
somehow preserved  Here are some such use cases:

$ cat c.c && gcc -O -S c.c
long f0 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 1);   // folded to n
}

long f1 (int n, char (*a)[n])
{
  return __builtin_dynamic_object_size (*a, 1);   // folded to -1 (fold to n?)
}

long f2 (int n, char a[1][n])
{
  return __builtin_dynamic_object_size (a[0], 1);   // folded to -1 (fold to
n?)
}

long f3 (int n, char a[static 1][n])
{
  return __builtin_dynamic_object_size (a, 1);   // ICE (fold to n?)
}

  parent reply	other threads:[~2022-03-21 17:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 15:24 [Bug tree-optimization/104970] New: " marxin at gcc dot gnu.org
2022-03-17 15:24 ` [Bug tree-optimization/104970] " marxin at gcc dot gnu.org
2022-03-17 17:50 ` siddhesh at gcc dot gnu.org
2022-03-21 11:59 ` [Bug tree-optimization/104970] [12 Regression] " jakub at gcc dot gnu.org
2022-03-21 12:19 ` jakub at gcc dot gnu.org
2022-03-21 17:19 ` msebor at gcc dot gnu.org
2022-03-21 17:22 ` msebor at gcc dot gnu.org [this message]
2022-03-21 18:18 ` jakub at gcc dot gnu.org
2022-03-22  0:25 ` msebor at gcc dot gnu.org
2022-03-23  5:56 ` siddhesh at gcc dot gnu.org
2022-03-23  7:28 ` jakub at gcc dot gnu.org
2022-03-23 15:34 ` msebor at gcc dot gnu.org
2022-03-24  9:40 ` cvs-commit at gcc dot gnu.org
2022-03-24  9:42 ` siddhesh at gcc dot gnu.org
2023-03-28 21:53 ` muecker at gwdg dot de
2023-03-29 11:15 ` siddhesh at gcc dot gnu.org
2023-03-30 17:17 ` muecker at gwdg dot de

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=bug-104970-4-VgEeioUh2a@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).