[Bug c/52920] New: function call optimized away with ftree-loop-distribute-patterns

[garfieldsk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52920

             Bug #: 52920
           Summary: function call optimized away with
                    ftree-loop-distribute-patterns
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: garfieldsk@gmail.com


Created attachment 27121
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27121
Archive of source code (temp.c), assembly (temp.s and temp2.s), preprocessed
source (temp.e), and verbose compilation logs (in case they are of use).

I've set this to critical, but I certainly acknowledge the possibility that the
fault lies somewhere on my end (so I apologize in advance if this isn't an
issue when you try to reproduce it).  I searched for this issue to see if
someone else had already seen similar, but didn't find it, and, if it is a real
issue, it seems like it could be important to pass on.

I've attached a simple (16 line) test example with a loop containing a printf
(the one that prints "Hi\n") that is optimized away in the presence of the
-ftree-loop-distribute-patterns flag in GCC 4.7.0 (I've tried this on Linux,
specifically CentOS 5.6 x86_64 and Ubuntu 10.10 x86).  I compiled the attached
code using the following:

gcc -O1 -ftree-loop-distribute-patterns temp.c

What I see when executable is run:
0

What I believe I should see when executable is run:
Hi
Hi
Hi
0

If the upper bound on the loop is changed to 1 (and 2 on the 32-bit Ubuntu
system), this code will work as expected, but as 3 or more (at least for the
few examples I tried), the printf is optimized away.  Looking at the attached
assembly (generated from the 64-bit CentOS system) for when the loop bound is 1
and when it is 2, you can see the printf call and even the string are not
present.  However, the zeros are written correctly (as evidenced by the last
printf and confirmed in the assembly).  I originally noticed this when calling
a custom malloc function, so I don't believe the behavior to be specific to
printf/IO functions.

This problem also occurred for me with -O3 and I was able to whittle it down to
the -O1 -ftree-loop-distribute-patterns, but I couldn't do the same for -O1
(namely, without -O1, even when including all flags enabled in gcc -Q
--help=optimizers, the problem doesn't show up).  Also, the previous compiler I
had was GCC 4.5.3, which doesn't have the -ftree-loop-distribute-patterns, and
this issue doesn't occur, even when compiling with -O3.

I tried removing the "A[i] = 0" or "B[i] = 0" lines...removing either one makes
the loop work as expected (no issue).  Similarly, removing the "int * test = A"
lines (and printing the value using A[0] instead of *test) works fine (no
issue).  However, just changing the "*test" to "A[0]" doesn't fix the issue.

I also attached the pre-processed source as well as the output of compiling
with -v in case these are of interest.