This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
- From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 27 Dec 2012 17:23:54 +0000
- Subject: [Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
- Auto-submitted: auto-generated
- References: <bug-55814-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-12-27 17:23:54 UTC ---
An even more pronounced test case, where we could sink
a lot more stores, which in fact could lead to moving
a whole loop:
logical function bar(a,b,c)
logical, intent(in) :: a, b
logical, intent(in), dimension(3) :: c
bar = a .and. b .and. any(c)
end
This is translated by the Fortran FE to
bar (logical(kind=4) & restrict a, logical(kind=4) & restrict b,
logical(kind=4)[3] * restrict c)
{
logical(kind=4) __result_bar;
{
logical(kind=4) test.0;
test.0 = 0;
{
integer(kind=8) S.1;
S.1 = 1;
while (1)
{
if (S.1 > 3) goto L.2;
if (NON_LVALUE_EXPR <(*c)[S.1 + -1]>)
{
test.0 = 1;
goto L.1;
}
S.1 = S.1 + 1;
}
L.2:;
}
L.1:;
__result_bar = (*a && *b) && test.0;
}
return __result_bar;
}
which the middle-end then doesn't optimize - there would
be no need to evaluate the loop if either a or b were false.