[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
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))
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))
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))
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))
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 :-)
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
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: = 0x0040e5f1 find_unequals+5571: mov0x1204(%rbx),%edx 0x0040e5f7 find_unequals+5577: mov$0x1,%eax 0x0040e5fc find_unequals+5582: shr%edx 0x0040e5fe find_unequals+5584: cmp%eax,%edx 0x0040e600 find_unequals+5586: jle0x40e604 find_unequals+5590 0x0040e602 find_unequals+5588: mov%edx,%eax 0x0040e604 find_unequals+5590: mov%eax,0x1330(%rbx) 0x0040e60a find_unequals+5596: mov0x1330(%rbx),%eax 0x0040e610 find_unequals+5602: add$0x1,%eax 0x0040e613 find_unequals+5605: mov0x1204(%rbx),%esi 0x0040e619 find_unequals+5611: mov%eax,0x133c(%rbx) 0x0040e61f find_unequals+5617: mov0x133c(%rbx),%eax 0x0040e625 find_unequals+5623: cmp%esi,%eax 0x0040e627 find_unequals+5625: jg 0x40ea50 find_unequals+6690 0x0040e62d find_unequals+5631: jmp0x40e630 find_unequals+5634 0x0040e62f find_unequals+5633: nop 0x0040e630 find_unequals+5634: mov0x133c(%rbx),%eax 0x0040e636 find_unequals+5640: cltq 0x0040e638 find_unequals+5642: test %rax,%rax 0x0040e63b find_unequals+5645: setle %dl 0x0040e63e find_unequals+5648: movzbl %dl,%edx 0x0040e641 find_unequals+5651: mov%edx,%edx 0x0040e643 find_unequals+5653: and$0x1,%edx 0x0040e646 find_unequals+5656: test %edx,%edx 0x0040e648 find_unequals+5658: je 0x40e666 find_unequals+5688 0x0040e64a find_unequals+5660: mov$0x1,%ecx 0x0040e64f find_unequals+5665: mov%rax,%rdx 0x0040e652 find_unequals+5668: mov$0x4820d8,%esi 0x0040e657 find_unequals+5673: mov$0x4827f0,%edi 0x0040e65c find_unequals+5678: mov$0x0,%eax 0x0040e661 find_unequals+5683: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e666 find_unequals+5688: cmp$0x12,%rax 0x0040e66a find_unequals+5692: setg %dl 0x0040e66d find_unequals+5695: movzbl %dl,%edx 0x0040e670 find_unequals+5698: mov%edx,%edx 0x0040e672 find_unequals+5700: and$0x1,%edx 0x0040e675 find_unequals+5703: test %edx,%edx 0x0040e677 find_unequals+5705: je 0x40e695 find_unequals+5735 0x0040e679 find_unequals+5707: mov$0x12,%ecx 0x0040e67e find_unequals+5712: mov%rax,%rdx 0x0040e681 find_unequals+5715: mov$0x482148,%esi 0x0040e686 find_unequals+5720: mov$0x4827f0,%edi 0x0040e68b find_unequals+5725: mov$0x0,%eax 0x0040e690 find_unequals+5730: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e695 find_unequals+5735: sub$0x1,%rax 0x0040e699 find_unequals+5739: add$0x4b8,%rax 0x0040e69f find_unequals+5745: mov0x4(%rbx,%rax,4),%eax 0x0040e6a3 find_unequals+5749: mov%eax,0x1200(%rbx) 0x0040e6a9 find_unequals+5755: mov0x1200(%rbx),%eax 0x0040e6af find_unequals+5761: add$0x1,%eax 0x0040e6b2 find_unequals+5764: movslq %eax,%rdx 0x0040e6b5 find_unequals+5767: test %rdx,%rdx 0x0040e6b8 find_unequals+5770: setle %al 0x0040e6bb find_unequals+5773: movzbl %al,%eax
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
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))
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))
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))
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))
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))
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))
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))
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.
