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?) }
next prev 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: linkBe 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).