A simple program should print "1" but prints "2". Of some reason MINLOC fails to find the minium location (first location) for the SUM expression. PROGRAM TST IMPLICIT NONE REAL :: A(1,3) A(:,1) = 10 A(:,2) = 20 A(:,3) = 30 WRITE(*,*) SUM(A(:,1:3),1) WRITE(*,*) MINLOC(SUM(A(:,1:3),1),1) END PROGRAM TST bash%> gfortran -o tst tst.f90 bash%> ./tst 10.00000 20.00000 30.00000 2 bash%>
The code compiles and runs correctly with trunk (aka 4.3). I'm guessing that Thomas had fixed the problem and that he did not back port the fix because the bug isn't a regression. If Thomas does not comment on the PR in a reasonable time, I'm inclinded to cloase the PR. Thanks for the bug report.
I want to add that you can find gfortran 4.3.0 binaries at http://gcc.gnu.org/wiki/GFortranBinaries I'm actually unsure which patch fixed it. It might be Paul's PR32298 even though it is about PARAMETER arrays.
(In reply to comment #2) > I want to add that you can find gfortran 4.3.0 binaries at > http://gcc.gnu.org/wiki/GFortranBinaries > > I'm actually unsure which patch fixed it. It might be Paul's PR32298 even > though it is about PARAMETER arrays. > Nah! I plead not guilty:-) Paul
Subject: Bug 33354 Author: tobi Date: Sat Sep 29 07:57:37 2007 New Revision: 128882 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128882 Log: PR fortran/33354 * gfortran.dg/minmaxloc_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/minmaxloc_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
I added a testcase for this. Can this bug be closed or does anyone feel strongly enough about it to fix it in 4.2?
(In reply to comment #5) > I added a testcase for this. Thanks! > Can this bug be closed or does anyone feel > strongly enough about it to fix it in 4.2? If we can identify which patch fixed this, I'd be in favor of backporting (even though we'll miss 4.2.2). Thomas
(In reply to comment #6) > (In reply to comment #5) > > I added a testcase for this. > Thanks! > > Can this bug be closed or does anyone feel > > strongly enough about it to fix it in 4.2? > If we can identify which patch fixed this, I'd be in favor > of backporting (even though we'll miss 4.2.2). > Thomas I think it's a pretty serious bug. Everyone who uses MINLOC or MAXLOC will silently get wrong result in certain cases and those intrinsics are fairly commonly used. It would sure be nice if this could be fixed in 4.2.3, to bad its to late for 4.2.2. Let me know if theres anything I can do to help.
I am currently trying to find the patch responsible for fixing this. This could indeed be Paul's fix for PR 32298 and 31726.
I can confirm that http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125983 fixes the problem for 4.2. As this is a particularly bad (i.e. silent wrong-code) bug, I propose to commit Paul's patch once 4.2 reopens.
There are only two later patches to min/maxloc, namely those for PRs 33297 and 32954, which both seem unrelated. So I agree that this should be safe to backport.
Subject: Bug 33354 Author: tkoenig Date: Mon Oct 15 18:23:39 2007 New Revision: 129365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129365 Log: 2007-10-25 Thomas Koenig <tkoenig@gcc.gnu.org> Paul Thomas <pault@gcc.gnu.org> PR fortran/32298 PR fortran/31726 PR fortran/33354 Backport from trunk * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Calculate the offset between the loop counter and the position as defined. Add the offset within the loop so that the mask acts correctly. Do not advance the location on the basis that it is zero. 2007-10-15 Thomas Koenig <tkoenig@gcc.gnu.org> PR fortran/33354 * gfortran.dg/minmaxloc_4.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/minmaxloc_4.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed.