[llvm-bugs] [Bug 35728] New: [ARM code-gen] Not passing all parameters in printf call

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35728

            Bug ID: 35728
           Summary: [ARM code-gen] Not passing all parameters in printf
                    call
           Product: clang
           Version: 4.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: andyg1001 at hotmail.co.uk
                CC: llvm-bugs at lists.llvm.org

Created attachment 19593
  --> https://bugs.llvm.org/attachment.cgi?id=19593&action=edit
Assembly output generated for code sample

I actually stumbled across this while trying to determine a test-case to find
another problem.

The code is quite possibly undefined behaviour (it certainly produces very
different outcomes when compiled for x86 vs ARM).  However, it seems to also
trigger a bug in the ARM code generator on clang 4.0.  I don't have a more
recent build to hand, so I haven't been able to test that.

The sample code is:

int main()
  {
  const float f = 10.0f;
  for (int i = 11; i < 15; ++i)
    {
    const unsigned u = f - i;
    printf("A %i %i\n", i, u);
    }

  for (int i = 1; i < 15; ++i)
    {
    const unsigned u = f - i;
    printf("B %i %i\n", i, u);
    }

  for (int i = 11; i < 15; ++i)
    {
    const unsigned u = f - i;
    printf("C %i %i\n", i, u);
    }

  return 0;
  }

Now, if I compile this for a Cortex-A9 ARM processor (-target
"arm-unknown-linux-gnueabihf" -mcpu="cortex-a9"), using clang-4.0.0 and
optimisation level 2, I get this output:

  A 11 2127129340
  A 12 1
  A 13 1
  A 14 1
  B 1 9
  B 2 8
  B 3 7
  B 4 6
  B 5 5
  B 6 4
  B 7 3
  B 8 2
  B 9 1
  B 10 0
  B 11 1
  B 12 1
  B 13 1
  B 14 1
  C 11 1
  C 12 1
  C 13 1
  C 14 1

Note that the first line changes every time the code is run.

GCC 4.8.5 for the same processor is more consistent and gives:

  A 11 0
  A 12 0
  A 13 0
  A 14 0
  B 1 9
  B 2 8
  B 3 7
  B 4 6
  B 5 5
  B 6 4
  B 7 3
  B 8 2
  B 9 1
  B 10 0
  B 11 0
  B 12 0
  B 13 0
  B 14 0
  C 11 0
  C 12 0
  C 13 0
  C 14 0

(Just for curiosities sake, on x86, you get negative numbers for i > 10 rather
than limiting to 0, and this is -- I assume -- the "undefined behaviour").

I have attached the assembly output from clang.  In it you can see that the
compiler has unrolled all the loops, but doesn't give "r2" a value for any line
where i > 10.

Note that if the "unsigned" types are changed to "int" OR the "float" type is
changed to "int" or "unsigned", then "r2" is always given a value (and a
negative one for i > 10 like you get on x86 for the original code).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171222/667a94ca/attachment.html>