[Bug fortran/56637] New: Bad result on max(1,shiftr(j,1))

[Bug fortran/56637] New: Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

             Bug #: 56637
           Summary: Bad result on max(1,shiftr(j,1))
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fkrogh#gcc@mathalacarte.com

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #1 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-16 18:02:49 UTC ---
I realize this is not much help for a bug report.  I can't get a small test
case to fail, and if I change the optimization level it works.  Also, I can't
be sure whether the problem is in the compiler or the library, but I suspect
the former.  Here is a small snippet of code

    k = max(1, shiftr(j,1)) ! The increment during the sort
    do ! Sort constraints to make active (Shell sort)
      do i = k + 1, j

In my small test case j is 13.  And k gets the value 1.  If I precede the first
statement with a garbage statement "i2=17" then after the first statement
above, k has the correct value of 6, even though the added statement should not
have changed the result.

Here are my flags


-ggdb -march=native -mpc80 -funroll-loops -pipe \
 -ftree-vectorize -floop-strip-mine \
 -floop-block -fimplicit-none -finit-real=NAN -fopenmp\
 -fcheck=bounds -Wall -Wextra

If I follow -ggdb with either -O1 or -O2 it gets the correct result.
This is running on a Gentoo Linux system, with Intel I7 CPU's.
Finally, here is a dump of the assembler code from the start of the first
statement.

Dump of assembler code from 0x40e5f1 to 0x40e6f1:
=> 0x000000000040e5f1 <find_unequals+5571>:     mov    0x1204(%rbx),%edx
   0x000000000040e5f7 <find_unequals+5577>:     mov    $0x1,%eax
   0x000000000040e5fc <find_unequals+5582>:     shr    %edx
   0x000000000040e5fe <find_unequals+5584>:     cmp    %eax,%edx
   0x000000000040e600 <find_unequals+5586>:     jle    0x40e604
<find_unequals+5590>
   0x000000000040e602 <find_unequals+5588>:     mov    %edx,%eax
   0x000000000040e604 <find_unequals+5590>:     mov    %eax,0x1330(%rbx)
   0x000000000040e60a <find_unequals+5596>:     mov    0x1330(%rbx),%eax
   0x000000000040e610 <find_unequals+5602>:     add    $0x1,%eax
   0x000000000040e613 <find_unequals+5605>:     mov    0x1204(%rbx),%esi
   0x000000000040e619 <find_unequals+5611>:     mov    %eax,0x133c(%rbx)
   0x000000000040e61f <find_unequals+5617>:     mov    0x133c(%rbx),%eax
   0x000000000040e625 <find_unequals+5623>:     cmp    %esi,%eax
   0x000000000040e627 <find_unequals+5625>:     jg     0x40ea50
<find_unequals+6690>
   0x000000000040e62d <find_unequals+5631>:     jmp    0x40e630
<find_unequals+5634>
   0x000000000040e62f <find_unequals+5633>:     nop
   0x000000000040e630 <find_unequals+5634>:     mov    0x133c(%rbx),%eax
   0x000000000040e636 <find_unequals+5640>:     cltq   
   0x000000000040e638 <find_unequals+5642>:     test   %rax,%rax
   0x000000000040e63b <find_unequals+5645>:     setle  %dl
   0x000000000040e63e <find_unequals+5648>:     movzbl %dl,%edx
   0x000000000040e641 <find_unequals+5651>:     mov    %edx,%edx
   0x000000000040e643 <find_unequals+5653>:     and    $0x1,%edx
   0x000000000040e646 <find_unequals+5656>:     test   %edx,%edx
   0x000000000040e648 <find_unequals+5658>:     je     0x40e666
<find_unequals+5688>
   0x000000000040e64a <find_unequals+5660>:     mov    $0x1,%ecx
   0x000000000040e64f <find_unequals+5665>:     mov    %rax,%rdx
   0x000000000040e652 <find_unequals+5668>:     mov    $0x4820d8,%esi
   0x000000000040e657 <find_unequals+5673>:     mov    $0x4827f0,%edi
   0x000000000040e65c <find_unequals+5678>:     mov    $0x0,%eax
   0x000000000040e661 <find_unequals+5683>:     callq  0x401d70
<_gfortran_runtime_error_at@plt>
   0x000000000040e666 <find_unequals+5688>:     cmp    $0x12,%rax
   0x000000000040e66a <find_unequals+5692>:     setg   %dl
   0x000000000040e66d <find_unequals+5695>:     movzbl %dl,%edx
   0x000000000040e670 <find_unequals+5698>:     mov    %edx,%edx
   0x000000000040e672 <find_unequals+5700>:     and    $0x1,%edx
   0x000000000040e675 <find_unequals+5703>:     test   %edx,%edx
   0x000000000040e677 <find_unequals+5705>:     je     0x40e695
<find_unequals+5735>
   0x000000000040e679 <find_unequals+5707>:     mov    $0x12,%ecx
   0x000000000040e67e <find_unequals+5712>:     mov    %rax,%rdx
   0x000000000040e681 <find_unequals+5715>:     mov    $0x482148,%esi
   0x000000000040e686 <find_unequals+5720>:     mov    $0x4827f0,%edi
   0x000000000040e68b <find_unequals+5725>:     mov    $0x0,%eax
   0x000000000040e690 <find_unequals+5730>:     callq  0x401d70
<_gfortran_runtime_error_at@plt>
   0x000000000040e695 <find_unequals+5735>:     sub    $0x1,%rax
   0x000000000040e699 <find_unequals+5739>:     add    $0x4b8,%rax
   0x000000000040e69f <find_unequals+5745>:     mov    0x4(%rbx,%rax,4),%eax
   0x000000000040e6a3 <find_unequals+5749>:     mov    %eax,0x1200(%rbx)
   0x000000000040e6a9 <find_unequals+5755>:     mov    0x1200(%rbx),%eax
   0x000000000040e6af <find_unequals+5761>:     add    $0x1,%eax
   0x000000000040e6b2 <find_unequals+5764>:     movslq %eax,%rdx
   0x000000000040e6b5 <find_unequals+5767>:     test   %rdx,%rdx
   0x000000000040e6b8 <find_unequals+5770>:     setle  %al
   0x000000000040e6bb <find_unequals+5773>:     movzbl %al,%eax
   0x000000000040e6be <find_unequals+5776>:     mov    %eax,%eax
   0x000000000040e6c0 <find_unequals+5778>:     and    $0x1,%eax
   0x000000000040e6c3 <find_unequals+5781>:     test   %eax,%eax
   0x000000000040e6c5 <find_unequals+5783>:     je     0x40e6e0
<find_unequals+5810>
   0x000000000040e6c7 <find_unequals+5785>:     mov    $0x1,%ecx
   0x000000000040e6cc <find_unequals+5790>:     mov    $0x481190,%esi
   0x000000000040e6d1 <find_unequals+5795>:     mov    $0x482818,%edi
   0x000000000040e6d6 <find_unequals+5800>:     mov    $0x0,%eax
   0x000000000040e6db <find_unequals+5805>:     callq  0x401d70
<_gfortran_runtime_error_at@plt>
   0x000000000040e6e0 <find_unequals+5810>:     cmp    $0x21,%rdx
   0x000000000040e6e4 <find_unequals+5814>:     setg   %al
   0x000000000040e6e7 <find_unequals+5817>:     movzbl %al,%eax
   0x000000000040e6ea <find_unequals+5820>:     mov    %eax,%eax
   0x000000000040e6ec <find_unequals+5822>:     and    $0x1,%eax
   0x000000000040e6ef <find_unequals+5825>:     test   %eax,%eax
End of assembler dump.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-03-16 18:16:10 UTC ---
What happens if you don't use the graphite options '-floop-strip-mine
-floop-block'?
How big is your "small test case" and on which libraries does it depends?

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #3 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-16 18:46:06 UTC ---
First some confusion.  If I single step over the first statement it works
properly. Once past that confusion, deleting both -floop-block and
-floop-strip-mine from the make file it still fails.

Although the test case I'm running is small, the actual code is quite large.

After realizing the problem with single stepping over the statement causing it
to work, I just tried that with the extra statement in front, and that actually
fails if I set the breakpoint after k is defined. So that part of my original
post should be ignored.

When I tried a small test case before, I had not used the same flags as caused
failure.  I just tried such a case, and it worked, so no luck in generating a
small test case.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-16 21:22:43 UTC ---
The symptoms you describe could indicate a classic error like
an index out of bounds error, an argument mismatch or a variable
which has not been set.

You could run your program under valgrind, and see if you
find anything.

You could also look the output from -fdump-tree-original
to see if anything looks wrong.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #5 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-16 21:25:46 UTC ---
I don't mean to be argumentative, but I would like to ask:
Would an index out of bounds explain why single stepping over the statement
make it work, and would it explain that a higher level of optimization works?

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-03-16 21:36:54 UTC ---
> I don't mean to be argumentative, but I would like to ask:
> Would an index out of bounds explain why single stepping over the statement
> make it work, and would it explain that a higher level of optimization works?

Absolutely: all the errors mentioned by Thomas give behaviors sensitive to the
memory layout! However if you compile with -fcheck=bounds, out of bounds
error(s) should be detected. Did you check that you pass the right arguments
(position, type, kind, ...) to the procedures in the libraries you are using?

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #7 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-16 21:44:46 UTC ---
As mentioned in my first post, I am compiling with -fcheck-bounds.  The errors
are occurring in a subroutine inside what at the moment is a main program. 
That subroutine has no arguments.  As this is code in the process of being
developed, I have had run time errors for indexes being out of bounds.  It
turns out as a result of thinking more about the problems I'm dealing with
(algorithmic issues) this part of the code is likely to disappear.  I do
appreciate others trying to find my problem, that is very nice.  I was posting
in the hope that I might help someone in finding a compiler bug.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-16 23:03:06 UTC ---

> I was posting
> in the hope that I might help someone in finding a compiler bug.

And we do appreciate that very much.

The problem is that without a self-contained example (i.e. one which
compiles and shows the erroneous behavior) we cannot do much.

If you can upload something which reproduces the problem, even if
it is large, we could then try to find the issue.

Would that be possible for you?

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #9 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-17 04:42:39 UTC ---
I have tried, but the small examples I've tried all work.  And the code uses a
library that I am not free to pass on.  Probably you just have to call this
unconfirmed and forget it.  Sorry.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-03-17
     Ever Confirmed|0                           |1

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-17 10:47:40 UTC ---
Can you run your program under valgrind?  What does this
tell you?

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> 2013-03-17 15:20:45 UTC ---
(In reply to comment #9)
> I have tried, but the small examples I've tried all work.  And the code uses a
> library that I am not free to pass on.  Probably you just have to call this
> unconfirmed and forget it.  Sorry.

There is an "automatic and recommended way" to reduce a testcase...
You can have a look at http://gcc.gnu.org/bugs/minimize.html

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #12 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-17 15:35:10 UTC ---
For those using valgrind on gentoo for the first time (like me) you need to add
to FEATURES in make.conf, "splitdebug" and re-emerge glibc.

I've tried running valgrind on my program with no options.  I does a lot of
complaining about a "use" statement in connection with a library I'm using. 
Other than this, the next error it finds is beyond the point where I think the
compiler goofed. The error found is one that my usual runtime also catches, and
is either due to the previous error, or my usual sloppiness. I would ordinarily
track down this error when I get to it.

If there are special features in valgrind that I should be using, let me know
and I'll give it a try.  At this point it should be easy.

I have tried making up a small example, but was unable to get the same problem.
 I'll try a bit more, but I don't think this is going to work.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[fkrogh#gcc at mathalacarte dot com]

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

--- Comment #13 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> 2013-03-17 16:40:22 UTC ---
As perhaps you have already guessed, this is just me being confused.  After
removing a lot of stuff from the code, I inserted a print statement thus

 620     k = max(1, shiftr(l,1)) ! The increment during the sort
 621     do ! Sort constraints to make active (Shell sort)
 622       do i = k + 1, l
 623         print '("i=",i0)', i

The break point is at line 621.  The print occurs before the break point is
reached.  The print shows that all is o.k.  I was confused as I thought the
breakpoint would be hit before getting into the loop.  Interestingly the
breakpoint has the behavior I expected with "-O1" or "-O2".

I'm sorry to have bothered you folks with this, but I'm glad to know a little
about valgrind.

[Bug fortran/56637] Bad result on max(1,shiftr(j,1))

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #14 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-17 17:05:35 UTC ---
OK, we can close it then.

Don't hesitate to come back with another bug report if you find anything :-)