[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #9 from Andrew Pinski --- (In reply to Hans-Peter Nilsson from comment #8) > There it is! I *knew* I had a PR entered for this, and was a bit surprised > when the ipa attribute was introduced, that this PR wasn't cross-referenced. > > Then again I guess most people don't check in bugzilla for possible entries > when they fix something, and this one maybe hasn't got any good terms to > look for. I think part of it is also finding it independently and fixing it without looking to see if someone has filed a bug report. I have found a few like this over the last few years as I try to clean up bugzilla for quality reports.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #8 from Hans-Peter Nilsson --- There it is! I *knew* I had a PR entered for this, and was a bit surprised when the ipa attribute was introduced, that this PR wasn't cross-referenced. Then again I guess most people don't check in bugzilla for possible entries when they fix something, and this one maybe hasn't got any good terms to look for. (In reply to Andrew Pinski from comment #7) > The noipa attribute is used for this now. It sure is and spot on.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- The noipa attribute is used for this now. In this case, adding noipa to foobar, removes the noreturn detection of foobar and there is no code difference with/without foobar defined in there. __attribute__ ((noipa)) extern void foobar(void *);
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 23:24:15 UTC --- Created attachment 27350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27350 preprocessed file with just the (previously) miscompiled function This is basically gcc.dg/torture/pr53272-1.c, here for completeness.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 23:41:41 UTC --- Created attachment 27351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351 Like i2.i (attachment 27350) but with main and auxiliary functions, and always aborting This attachment was an edit-in-progress adding functions to make the test-case runnable, but with an error that isn't in gcc.dg/torture/pr53272-2.c: the foobar function always aborts, making the test-case always abort. This leads to different code being generated for the key function rtc_update_irq_enable. The difference seems to be the same as for calling an explicit or computed noreturn function, which would be an ok optimization if cross-function optimization was wanted. Changing the empty line in foobar to if (foo(x)) as in gcc.dg/torture/pr53272-2.c yields the expected same generated code as for i2.i. So, while it exposes an unwanted optimization, for this case it is benevolent; the goal was add framework to make the case runnable, not aborting. :) Though, I bet I can cook up a C++ case that throws (or C that rethrows) before the aborting call, and the code have the same unwanted difference in presence of the aborting foobar.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-08 23:48:06 UTC --- You seem to be hitting the logic detecting functions executed just once and making them optimized for size rather than speed. Usual way to avoid it in the testsuite is to put a loop into main().
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Attachment #27351|application/octet-stream|text/plain mime type|| --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-09 00:01:56 UTC --- Comment on attachment 27351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351 Like i2.i (attachment 27350) but with main and auxiliary functions, and always aborting Correcting type of attachment to text/plain.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-09 00:04:08 UTC --- (In reply to comment #3) You seem to be hitting the logic detecting functions executed just once and making them optimized for size rather than speed. No, not really once, but noreturn. Maybe both. :/
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-09 00:13:44 UTC --- (In reply to comment #3) Usual way to avoid it in the testsuite is to put a loop into main(). Besides, the background of this PR (at the URL) is that I don't want a recipe that works for this-optimization and this-code; I want a way to disable cross-function-optimizations once and for all, preferably with defined function-granular borders, like disabling in and out of specific functions.
