On 1/28/21 2:22 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:+ if (TREE_CODE (bound) == PLUS_EXPR + && integer_all_onesp (TREE_OPERAND (bound, 1))) + { + bound = TREE_OPERAND (bound, 0); + if (TREE_CODE (bound) == NOP_EXPR) + bound = TREE_OPERAND (bound, 0); + }so it either does or does not strip a -1 but has no indication on whether it did that? That looks fragile and broken.Yeah. Plus again STRIP_NOPs in there should be used. But certainly it needs to remember whether there was + -1 or not and compensate for it.The free-lang-data parts are OK.But is fld the right spot to do it? If it is only the FE that emits the warnings, shouldn't it be stripped already before gimplification so that it isn't actually corrupted? I mean in c_parse_final_cleanups or c_common_parse_file depending on if it is just C or C++ too?
I've been asking for a good place to do it since December and free_lang_data was the only suggestion. I even mentioned it to you this Tuesday. c_parse_final_cleanups looks like a better place but I don't understand why you've waited until now to point me to it.
Plus, if the expressions in the attribute don't contain SAVE_EXPRs, why
there isn't unshare_expr called on them (and if they do, I don't see how
it would be guaranteed, can't one e.g. do
int bar (void);
void foo (int n, int a[n + 1][bar () + 2], int b[sizeof (a[0]) + 32])
{
}
?) the unsharing variant I've pasted into the PR.
I'm not sure what you're asking here or if you're just repeating the same question we went over in November when I posted the first patch to unshare the expressions. In that thread, after I explained that the expressions in the attribute aren't evaluated, you ultimately agreed it wasn't necessary: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559953.html The front end wraps each VLA bound that needs to be evaluated in a SAVE_EXPR (and, as Joseph points out in the same thread, if there are more of them, they're wrapped in a COMPOUND_EXPR). But the attribute doesn't use these SAVE_EXPRs -- instead, it uses the expressions before they're wrapped. This wasn't a choice I made deliberately. I just didn't know about the COMPOUND_EXPR wrapped bounds. Martin
