[Bug fortran/31608] wrong types in array transfer
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 --- Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) Well, we do. if (any (Up (AbCdEfGhIjKlM) .ne. (/ABCDEFGHIJKLM/))) stop 'ERROR' compiles with - NAG f95 5.1(346) - g95 -std=f95 -W -Wall -Wextra -pedantic 4.0.3 (g95 0.91!) Feb 23 2007 - ifort -stand f95 -warn all (9.1.040, 10.0.017beta) - sunf95 -w4 8.3 Build35_2 2006/12/04 And, of cause, it does not have anything to do with Fortran 2003 (The following would be: up(abcdef) - function up(string); character(len=1), dimension(:) :: string). What we have here is: 7.1.5 Conformability rules for elemental operations [...] For all elemental binary operations, the two operands shall be in shape conformance. In the case where one is a scalar and the other an array, the scalar is treated as if it were an array of the same shape as the array operand with every element, if any, of the array equal to the value of the scalar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-04-19 09:08 --- Subject: Re: wrong types in array transfer burnus at gcc dot gnu dot org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 --- Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) Well, we do. That doesn't make it any less embarassing :) But indeed this is the same as 1 .eq. (/1,2/) which evaluates to (/.true.,.false./), should have thought of this earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-19 10:37 --- (In reply to comment #7) I am completely trapped by the workshop that I am running and have not even managed to do what I promised last night. Realistically, it might have to wait until the weekend. If you can develop a description of what the real PR should be, I would be grateful. BTW - thanks to Richard for noticing it.. might I ask how you came across it? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-19 12:08 --- The patch in http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html makes the testcase ICE because of the type mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #10 from pault at gcc dot gnu dot org 2007-04-19 15:20 --- (In reply to comment #5) For the record, the problem Richard is pointing out is in the body of the function Up, namely in the expression for MERGE, probably caused by TRANSFER. Duuh! You are right about where the problem is. Look, I am not in a position to usefully contribute right now. Please take such action as you see fit; eg. withdraw the testcase and restore the PR, so that Richard can get going. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-19 15:55 --- It's not blocking me atm as a different patch got accepted which doesn't expose this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-18 09:36 --- (In reply to comment #1) Adding pault, as he's the likely culprit :) Richard and Tobi, I am a bit trapped right now, as chairman of a review meeting; I'll try to look at it this evening. On the face of it, character*(20) .ne. array of character*(1) should not be allowed! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-18 10:21 --- (In reply to comment #1) snip if (any (Up (AbCdEfGhIjKlM) .ne. (/ABCDEFGHIJKLM/))) call abort () contains Character (len=20) Function Up (string) /snip It looks like it's comparing a CHARACTER*20 (= Up's result) to an array of characters (= the array constructor). I think this is not allowed in Fortran 95 mode, but I'm not 100% sure about Fortran 2003; I think it is also not allowed, but one has to check the standard (cf. PR30940). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-18 10:44 --- (In reply to comment #2) Changing the comparison to if (Up (AbCdEfGhIjKlM) .ne. ABCDEFGHIJKLM) call abort () gets rid of the problem. I have clearly exposed something extremely unpleasant in ANY or the comparison that needs to be stopped by the front-end. I will test and commit the modified testcase, under the obvious rule, tonight. In addition, I will pin down the frontend bug and transmute this PR to reflect that. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-18 23:56 --- For the record, the problem Richard is pointing out is in the body of the function Up, namely in the expression for MERGE, probably caused by TRANSFER. Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-17 17:27 --- Adding pault, as he's the likely culprit :) Paul, I'm wondering if the testcase is really valid Fortran: snip if (any (Up (AbCdEfGhIjKlM) .ne. (/ABCDEFGHIJKLM/))) call abort () contains Character (len=20) Function Up (string) /snip It looks like it's comparing a CHARACTER*20 (= Up's result) to an array of characters (= the array constructor). I don't see how I could confirm confusion of the middle-end :-) -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
