[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81009 --- Comment #8 from Eric Gallager --- (In reply to Eyal Rozenberg from comment #2) > (In reply to Marc Glisse from comment #1) > > Seems similar enough. > > With respect - this is not about x being a const __restrict pointer; what I > said (including the clang behavior) applies exactly the same when we remove > the const. See: https://godbolt.org/z/hH643a (where the const is gone). OK, but even if it's not a dup, I still think it's related enough to go under "See Also"
[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 --- Comment #7 from rguenther at suse dot de --- On Tue, 26 Feb 2019, eyalroz at technion dot ac.il wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 > > --- Comment #5 from Eyal Rozenberg --- > (In reply to Richard Biener from comment #4) > > exposing __restrict to the IL). > > Is "IL" an acronym for "Intermediate Language"? Remember many bug > posters/readers are not GCC developers and don't know all the lingo. Yes. > > To elaborate further to successfully mark a function call > > with clique == 1 and base == 0 we have to prove the pointer marked restrict > > doesn't escape the function through calls > > Certainly, calling g() could be just the same as writing to an alias of the x > pointer. But - __restrict is how we guarantee this doesn't happen (or can be > ignored) even when the compiler can't prove that's the case on its own. So I'm > not sure I understand what you're suggesting with your comment. I suppose you > could try and "disprove the __restrict" to give a warning, but other than that > - why not just respect it? Well, "respecting" it means encoding it in the intermediate language which we don't at the moment for calls.
[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 --- Comment #6 from Eyal Rozenberg --- Thanks to a friendly StackOverflow user, I should also report that (about) the same code produces the same compiler behavior disparity for proper C: https://godbolt.org/z/kVYqp8 with the slight modification being `void g(void)` instead of `void g()` in the function signatures.
