This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
- From: "hp at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 08 May 2012 23:41:41 +0000
- Subject: [Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
- Auto-submitted: auto-generated
- References: <bug-53273-4@http.gcc.gnu.org/bugzilla/>
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.