Created attachment 48928 [details] Test case Attached file contains an invalid call of a "type-bound procedure" A = T%R1%GET(I) where T%R1 is not a derived type at all, it is a REAL(REAL64). With the following compiler: Target: x86_64-pc-linux-gnu Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0 Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) and compilation command: $ gfortran -c -o test.o test.f90 the code is accepted. With version 10.1.0, the code is also accepted. With version 8.3.0, the following error is reported: test.f90:37:4: A = T%R1%GET(I) 1 Error: Unclassifiable statement at (1)
(In reply to Kirill Chilikin from comment #0) > Created attachment 48928 [details] > Test case > > Attached file contains an invalid call of a "type-bound procedure" > > A = T%R1%GET(I) > > where T%R1 is not a derived type at all, it is a REAL(REAL64). > > With the following compiler: > > Target: x86_64-pc-linux-gnu > Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0 > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 10.2.0 (GCC) > > and compilation command: > > $ gfortran -c -o test.o test.f90 > > the code is accepted. With version 10.1.0, the code is also accepted. > With version 8.3.0, the following error is reported: > > test.f90:37:4: > > A = T%R1%GET(I) > 1 > Error: Unclassifiable statement at (1) Looks like a bug in your code. Module m2 does not use anything from module m1, so that appears to be a red herring. There is no type bound procedure. Your code example then reduces to module m2 type t2 real r1 end type contains pure subroutine s(t, a) implicit none type(t2), intent(in) :: t real, intent(out) :: a integer i a = t%r1%get(i) end subroutine end module and gfortran is telling you that it cannot parse 'a = t%r1%get(i)' the part-ref for %get(i) is bogus, ie., the statement cannot be classified as Fortran.
Yes, there is no type-bound procedure really, and, yes, there is a bug in the code (intentionally: it was called for the wrong variable, which is removed for the test case). The module M2 indeed does not use anything from M1 (due to simplification of the real code). And, yes, the gfortran should tell that this statement is not classifiable - 8.3.0 does this, but 10.2.0 successfully compiles the code without reporting any error.
I tested the reduced test case. It also compiles successfully with version 10.2.0, while it should not. With 8.3.0, an error is reported: $ /usr/bin/gfortran -c -o test.o test2.f90 test2.f90:14:9: a = t%r1%get(i) 1 Error: Unclassifiable statement at (1)
Thus, this error (or, more exactly, absence of error) does not depend on the presence of a type-bound procedure with the same name for another derived type. The bug description should probably be modified.
(In reply to Kirill Chilikin from comment #3) > I tested the reduced test case. It also compiles successfully with version > 10.2.0, while it should not. With 8.3.0, an error is reported: > > $ /usr/bin/gfortran -c -o test.o test2.f90 > test2.f90:14:9: > > a = t%r1%get(i) > 1 > Error: Unclassifiable statement at (1) Whoops. I misread which version compiled the code and which one issued the error. This is, indeed a bug, a very strange bug! For this code, module m2 implicit none type t2 integer r1 end type contains subroutine s(t, a) type(t2), intent(in) :: t integer, intent(out) :: a integer i i = t%r1 a = t%r1%foo(i) end subroutine end module if I change t%r1%foo(i) to either t%r1(i) or t%r1%foo%bar(i), gfortran will generate the unclassifiable statement error. Compiling the code with -fdump-tree-original reveals s (struct t2 & restrict t, integer(kind=4) & restrict a) { integer(kind=4) i; i = t->r1; *a = i; } i = t->r1 is correctly referencing the component of t. *a = i is as-if t->r1->foo is an identity operator i
This is a nasty bug, and I've run out of ideas on how to find a fix. :( Simplified testcase implicit none type t2 integer r1 end type type(t2) :: t integer :: a a = t%r1%foo(1) ! There is no foo component/TBP if (a == 42) stop end -fdump-tree-original gives MAIN__ () { integer(kind=4) a; struct t2 t; a = 1; if (a == 42) { _gfortran_stop_string (0B, 0, 0); } L.1:; }
Result of git bisect: $ git bisect log git bisect start # bad: [6e6e3f144a33ae504149dc992453b4f6dea12fdb] Update ChangeLog and version files for release git bisect bad 6e6e3f144a33ae504149dc992453b4f6dea12fdb # good: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files for GCC 8. git bisect good 406c2abec3f998e9064919b22db62f38a7c0e7b9 # good: [7d75ea04cf6d9c8960d5c6119d6203568b7069e9] re PR c++/85437 (member pointer static upcast rejected in a constexpr context) git bisect good 7d75ea04cf6d9c8960d5c6119d6203568b7069e9 # good: [5fae049dc272144f8e61af94ee0ba42b270915e5] OpenACC Profiling Interface (incomplete) git bisect good 5fae049dc272144f8e61af94ee0ba42b270915e5 # bad: [271da732841345d3834cf458d47f8242ac5ef513] PR testsuite/92127: Disable unrolling for some vect code model cases git bisect bad 271da732841345d3834cf458d47f8242ac5ef513 # good: [4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9] [Ada] New parameter Quiet for procedure GNAT.Command_Line.Getopt git bisect good 4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9 # bad: [0968003dd08a9e9f83bee955bbdc259a781f044f] PR c++/91819 - ICE with operator++ and enum. git bisect bad 0968003dd08a9e9f83bee955bbdc259a781f044f # good: [32b1d51f16fe56b34e979fcfba4bc74dbd3592a9] runtime: move osinit to Go git bisect good 32b1d51f16fe56b34e979fcfba4bc74dbd3592a9 # bad: [a1fc3891ebb77c1bdf68ce70c074eb907d21771a] go/internal/gccgoimporter: support embedded field in pointer loop git bisect bad a1fc3891ebb77c1bdf68ce70c074eb907d21771a # bad: [e7414688f16c4c9db2dacbc31da683887b4ba1bd] re PR middle-end/90501 (ICE: address taken, but ADDRESSABLE bit not set) git bisect bad e7414688f16c4c9db2dacbc31da683887b4ba1bd # good: [a37ab089c22f8be834bb1b5fd4c0454224db9b0f] 2019-09-01 François Dumont <fdumont@gcc.gnu.org> git bisect good a37ab089c22f8be834bb1b5fd4c0454224db9b0f # bad: [c6c2d1bc9bc3eb3606af6a198e74170bd906e199] re PR other/79543 (Inappropriate "ld --version" checking) git bisect bad c6c2d1bc9bc3eb3606af6a198e74170bd906e199 # good: [1525fa83cc704ba18738eb2eab76a7f4d6bfde6b] re PR tree-optimization/91632 (Probably wrong code since r275026) git bisect good 1525fa83cc704ba18738eb2eab76a7f4d6bfde6b # bad: [75f935365dba3eb5e9cbd11bc0d75009cad3d019] [AArch64] Add Linux hwcap strings for some extensions git bisect bad 75f935365dba3eb5e9cbd11bc0d75009cad3d019 # bad: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447) git bisect bad f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 # good: [be0fb5484a64414878c31a1606b07175b54ecb90] re PR fortran/91552 (ICE with valid array constructor) git bisect good be0fb5484a64414878c31a1606b07175b54ecb90 # first bad commit: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447) f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 Author: Paul Thomas <pault@gcc.gnu.org> Date: Mon Sep 2 19:54:02 2019 +0000 re PR fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447) 2019-09-02 Paul Thomas <pault@gcc.gnu.org> PR fortran/91589 * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent component ref, when the primary type is intrinsic. 2019-09-02 Paul Thomas <pault@gcc.gnu.org> PR fortran/91589 * gfortran.dg/pr91589.f90 : New test. From-SVN: r275324
(In reply to Kirill Chilikin from comment #7) > Result of git bisect: > (bisection removed) > f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit > commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 > Author: Paul Thomas <pault@gcc.gnu.org> > Date: Mon Sep 2 19:54:02 2019 +0000 > > re PR fortran/91589 (ICE in gfc_conv_component_ref, at > fortran/trans-expr.c:2447) > > 2019-09-02 Paul Thomas <pault@gcc.gnu.org> > > PR fortran/91589 > * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent > component ref, when the primary type is intrinsic. > > 2019-09-02 Paul Thomas <pault@gcc.gnu.org> > > PR fortran/91589 > * gfortran.dg/pr91589.f90 : New test. > > From-SVN: r275324 Thank for the bisection. The system I'm sitting in front of is too slow to attempt a bisection. I have developed a patch, which yields % gfcx -c a.f90 a.f90:11:16: 11 | a = t%r1%foo(1) ! There is no foo component/TBP. | 1 Error: 'foo' at (1) is not a component of the derived type 't2' For the last testcase I posted. I have not regression tested the patch, so have no ideas if there are unforeseen side-effects. I'll just put the patch here for others to find. Index: gcc/fortran/primary.c =================================================================== --- gcc/fortran/primary.c (revision 280157) +++ gcc/fortran/primary.c (working copy) @@ -2240,6 +2240,16 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, inquiry = is_inquiry_ref (name, &tmp); if (inquiry) sym = NULL; + else + { + component = gfc_find_component (sym, name, false, false, &tmp); + if (!component) + { + gfc_error ("%qs at %C is not a component of the derived " + "type %qs", name, sym->name); + return MATCH_ERROR; + } + } if (sep == '%' && primary->ts.type != BT_UNKNOWN) intrinsic = true;
I regression tested the patch in comment 8 and see these failures. FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14) FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors)
(In reply to jvdelisle from comment #9) > I regression tested the patch in comment 8 and see these failures. > > FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14) > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors) Thanks for testing. Does the patch that follows fix the regressions? gfortran treats components and type bound procedures separately. I've (hopefully) adapted the patch to whether foo is either. Index: gcc/fortran/primary.c =================================================================== --- gcc/fortran/primary.c (revision 280157) +++ gcc/fortran/primary.c (working copy) @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, inquiry = is_inquiry_ref (name, &tmp); if (inquiry) sym = NULL; + else + { + component = gfc_find_component (sym, name, false, false, &tmp); + tbp = gfc_find_typebound_proc (sym, &t, name, false, &gfc_current_locus); + if (!component && !tbp) + { + gfc_error ("%qs at %C is neither a component nor a type " + "bound procedure of the derived " + "type %qs", name, sym->name); + return MATCH_ERROR; + } + } if (sep == '%' && primary->ts.type != BT_UNKNOWN) intrinsic = true;
(In reply to kargl from comment #10) ---snip--- > Thanks for testing. Does the patch that follows fix the regressions? > gfortran treats components and type bound procedures separately. I've > (hopefully) adapted the patch to whether foo is either. > ---snip--- Patch at comment 10 passes patch provided in comment 10 passes regression testing. I will commit to trunk and use the original case as a test case tomorrow.
(In reply to kargl from comment #10) > (In reply to jvdelisle from comment #9) > > I regression tested the patch in comment 8 and see these failures. > > > > FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14) > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors) > > Thanks for testing. Does the patch that follows fix the regressions? > gfortran treats components and type bound procedures separately. I've > (hopefully) adapted the patch to whether foo is either. > > Index: gcc/fortran/primary.c > =================================================================== > --- gcc/fortran/primary.c (revision 280157) > +++ gcc/fortran/primary.c (working copy) > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, > inquiry = is_inquiry_ref (name, &tmp); > if (inquiry) > sym = NULL; > + else > + { > + component = gfc_find_component (sym, name, false, false, &tmp); > + tbp = gfc_find_typebound_proc (sym, &t, name, false, > &gfc_current_locus); > + if (!component && !tbp) > + { > + gfc_error ("%qs at %C is neither a component nor a type " > + "bound procedure of the derived " > + "type %qs", name, sym->name); > + return MATCH_ERROR; > + } > + } > > if (sep == '%' && primary->ts.type != BT_UNKNOWN) > intrinsic = true; Hi Steve, Given your comment 6, I set too first thing this morning and located the bug by searching the ChangeLogs for candidates. That I was the culprit is galling to say the least of it. My version of the fix is: index d73898473df..6f032fbabfd 100644 --- a/gcc/fortran/primary.c +++ b/gcc/fortran/primary.c @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag, else component = NULL; - /* In some cases, returning MATCH_NO gives a better error message. Most - cases return "Unclassifiable statement at..." */ if (intrinsic && !inquiry) - return MATCH_NO; + { + gfc_error ("%qs at %C is not an inquiry reference to an " + "intrinsic type", name); + return MATCH_ERROR; + } else if (component == NULL && !inquiry) return MATCH_ERROR; Just a couple of nits concerning your patch: The false typebound call appears after the 'r1' components ref, which is not a derived type or class type. That is why the test for an inquiry reference is appropriate and is tested for in this block. Your error message comes up with t2 as being the type. I suggest: > + gfc_error ("%qs at %C is not an inquiry reference to an " > + "intrinsic type", name); or some such. Also, you have to get rid of the comment and the dead code that was modified in my patch. Thanks for the patch. OK for trunk when the error message is corrected and the comment plus dead code removed. Cheers Paul
On Wed, Jul 29, 2020 at 02:54:59PM +0000, pault at gcc dot gnu.org wrote: > --- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> --- > (In reply to kargl from comment #10) > > (In reply to jvdelisle from comment #9) > > > I regression tested the patch in comment 8 and see these failures. > > > > > > FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) > > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14) > > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors) > > > > Thanks for testing. Does the patch that follows fix the regressions? > > gfortran treats components and type bound procedures separately. I've > > (hopefully) adapted the patch to whether foo is either. > > > > Index: gcc/fortran/primary.c > > =================================================================== > > --- gcc/fortran/primary.c (revision 280157) > > +++ gcc/fortran/primary.c (working copy) > > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, > > inquiry = is_inquiry_ref (name, &tmp); > > if (inquiry) > > sym = NULL; > > + else > > + { > > + component = gfc_find_component (sym, name, false, false, &tmp); > > + tbp = gfc_find_typebound_proc (sym, &t, name, false, > > &gfc_current_locus); > > + if (!component && !tbp) > > + { > > + gfc_error ("%qs at %C is neither a component nor a type " > > + "bound procedure of the derived " > > + "type %qs", name, sym->name); > > + return MATCH_ERROR; > > + } > > + } > > > > if (sep == '%' && primary->ts.type != BT_UNKNOWN) > > intrinsic = true; > > Hi Steve, > > Given your comment 6, I set too first thing this morning and > located the bug by searching the ChangeLogs for candidates. That > I was the culprit is galling to say the least of it. Don't be too galled (is that a word?). You've contributed to so many areas of the compiler and the Fortran language is only getting more complicated! For my patch, I noted that is_inquiry_ref tested for %re, %im, %len, and %kind. As that returns false, the only thing that %foo(i) can be is either a component (which happens to be an array) or type-bound procedure. > My version of the fix is: > > index d73898473df..6f032fbabfd 100644 > --- a/gcc/fortran/primary.c > +++ b/gcc/fortran/primary.c > @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, > bool sub_flag, > else > component = NULL; > > - /* In some cases, returning MATCH_NO gives a better error message. Most > - cases return "Unclassifiable statement at..." */ > if (intrinsic && !inquiry) > - return MATCH_NO; > + { > + gfc_error ("%qs at %C is not an inquiry reference to an " > + "intrinsic type", name); > + return MATCH_ERROR; > + } This works for me. Note, jerryd is in the process of committing my patch as I do not use git (and currently no one is paying me to learn git). > > + gfc_error ("%qs at %C is not an inquiry reference to an " > > + "intrinsic type", name); > > or some such. I suppose the above error message works. The message I came up with is due to the (i) in %foo(i). Is this a typo for an array or TBP? Either way the error is now detected. > > Also, you have to get rid of the comment and the dead code that > was modified in my patch. > > Thanks for the patch. OK for trunk when the error message is > corrected and the comment plus dead code removed. I do not know git. I do not use git for my personal projects, so there is no incentive for me to waste my time learning what has become a bane. I am stuck at svn r280157 (Jan 2020 or so). AFAICT, from reading gcc mailing list arhives, the switch from subversion to git was not publically discussed. All discussion (from a very small group of people) makes it clear the conversion was going to happen. It seems there was no consideration for the negative impact the switch will have. But, then again, gfortran is an after thought for most. You'll find a bunch of patches attached to PRs, which need a (hopefully new) gfortran committer to look: mobile:kargl[204] ls pr*diff pr30371.diff pr95586.diff pr30371_umask.diff pr95612.diff pr30371_umask_sub.diff pr95613.diff pr30371_unlink_sub.diff pr95614.diff pr69101.diff pr95647.diff pr85796.diff pr95708.diff pr93635.diff pr95709.diff pr95038.diff pr95710.diff pr95340.diff pr95829.diff pr95342.diff pr95980.diff pr95352.diff pr95981.diff pr95372.diff pr96013.diff pr95446.diff pr96025.diff pr95501.diff pr96038.diff pr95502.diff pr96102.diff pr95543.diff pr96320.diff pr95584.diff pr96325.diff pr95585.diff
Hi Steve, Your opinion of git and the change over to it is much the same as mine. I have given it a go but had several "accidents" which put me off for a bit. As for working on the branches.... well, I won't even begin to describe what a dog's dinner that is. ChangeLogs are stuffed (or were) and I still haven't found out how to update Bugzilla automatically. I haven't had the energy to try again these last few months, largely because I am finding home working so knackering. Sitting in front of the screen all day is causing me irritated eyes and the occasional blinder of a headache. I have taken note of your PRs with fixes on them - I'll maybe use them as an adventure into gitland :-) I see that Washington is just above the threshold of testing positivity and that it is increasing. Has that resulted in a response yet? My younger son lives in Mountain View and is going crazy with the new statewide restrictions. They have two kids in a relatively small house and are both trying to work from home. With no summer camps they are heading to another bout of cabin fever. galling /ˈɡɔːlɪŋ/ Learn to pronounce <https://www.google.com/search?rlz=1C1GCEU_enGB907GB908&sxsrf=ALeKk01WAFKiVjkfMVbAjEnkFQRgGWBs4Q:1596041502131&q=how+to+pronounce+galling&stick=H4sIAAAAAAAAAOMIfcRoyS3w8sc9YSmDSWtOXmPU4uINKMrPK81LzkwsyczPExLmYglJLcoV4pbi5GJPT8zJycxLt2JRYkrN41nEKpGRX65Qkq9QANSSD9STqgBVAQBz5NcbWQAAAA&pron_lang=en&pron_country=gb&sa=X&ved=2ahUKEwjc3Z_29fLqAhUIVBUIHdkNCtcQ3eEDMAB6BAgHEAg> *adjective* 1. causing annoyance or resentment; annoying. "it would be galling to lose your job because of a dispute with a customer" Cheers Paul On Wed, 29 Jul 2020 at 17:19, sgk at troutmask dot apl.washington.edu < gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 > > --- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> > --- > On Wed, Jul 29, 2020 at 02:54:59PM +0000, pault at gcc dot gnu.org wrote: > > --- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> --- > > (In reply to kargl from comment #10) > > > (In reply to jvdelisle from comment #9) > > > > I regression tested the patch in comment 8 and see these failures. > > > > > > > > FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) > > > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, > line 14) > > > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess > errors) > > > > > > Thanks for testing. Does the patch that follows fix the regressions? > > > gfortran treats components and type bound procedures separately. I've > > > (hopefully) adapted the patch to whether foo is either. > > > > > > Index: gcc/fortran/primary.c > > > =================================================================== > > > --- gcc/fortran/primary.c (revision 280157) > > > +++ gcc/fortran/primary.c (working copy) > > > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int > equiv_flag, > > > inquiry = is_inquiry_ref (name, &tmp); > > > if (inquiry) > > > sym = NULL; > > > + else > > > + { > > > + component = gfc_find_component (sym, name, false, false, > &tmp); > > > + tbp = gfc_find_typebound_proc (sym, &t, name, false, > > > &gfc_current_locus); > > > + if (!component && !tbp) > > > + { > > > + gfc_error ("%qs at %C is neither a component nor a type " > > > + "bound procedure of the derived " > > > + "type %qs", name, sym->name); > > > + return MATCH_ERROR; > > > + } > > > + } > > > > > > if (sep == '%' && primary->ts.type != BT_UNKNOWN) > > > intrinsic = true; > > > > Hi Steve, > > > > Given your comment 6, I set too first thing this morning and > > located the bug by searching the ChangeLogs for candidates. That > > I was the culprit is galling to say the least of it. > > Don't be too galled (is that a word?). You've contributed to so > many areas of the compiler and the Fortran language is only getting > more complicated! > > For my patch, I noted that is_inquiry_ref tested for %re, %im, > %len, and %kind. As that returns false, the only thing that > %foo(i) can be is either a component (which happens to be an > array) or type-bound procedure. > > > My version of the fix is: > > > > index d73898473df..6f032fbabfd 100644 > > --- a/gcc/fortran/primary.c > > +++ b/gcc/fortran/primary.c > > @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int > equiv_flag, > > bool sub_flag, > > else > > component = NULL; > > > > - /* In some cases, returning MATCH_NO gives a better error > message. Most > > - cases return "Unclassifiable statement at..." */ > > if (intrinsic && !inquiry) > > - return MATCH_NO; > > + { > > + gfc_error ("%qs at %C is not an inquiry reference to an " > > + "intrinsic type", name); > > + return MATCH_ERROR; > > + } > > This works for me. Note, jerryd is in the process of committing > my patch as I do not use git (and currently no one is paying me > to learn git). > > > > + gfc_error ("%qs at %C is not an inquiry reference to an " > > > + "intrinsic type", name); > > > > or some such. > > I suppose the above error message works. The message I came up > with is due to the (i) in %foo(i). Is this a typo for an array > or TBP? Either way the error is now detected. > > > > > Also, you have to get rid of the comment and the dead code that > > was modified in my patch. > > > > Thanks for the patch. OK for trunk when the error message is > > corrected and the comment plus dead code removed. > > I do not know git. I do not use git for my personal projects, > so there is no incentive for me to waste my time learning what > has become a bane. I am stuck at svn r280157 (Jan 2020 or so). > AFAICT, from reading gcc mailing list arhives, the switch from > subversion to git was not publically discussed. All discussion > (from a very small group of people) makes it clear the conversion > was going to happen. It seems there was no consideration for > the negative impact the switch will have. But, then again, > gfortran is an after thought for most. > > You'll find a bunch of patches attached to PRs, which need a > (hopefully new) gfortran committer to look: > > mobile:kargl[204] ls pr*diff > pr30371.diff pr95586.diff > pr30371_umask.diff pr95612.diff > pr30371_umask_sub.diff pr95613.diff > pr30371_unlink_sub.diff pr95614.diff > pr69101.diff pr95647.diff > pr85796.diff pr95708.diff > pr93635.diff pr95709.diff > pr95038.diff pr95710.diff > pr95340.diff pr95829.diff > pr95342.diff pr95980.diff > pr95352.diff pr95981.diff > pr95372.diff pr96013.diff > pr95446.diff pr96025.diff > pr95501.diff pr96038.diff > pr95502.diff pr96102.diff > pr95543.diff pr96320.diff > pr95584.diff pr96325.diff > pr95585.diff > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Hi Paul, Not sure how the UK is handling the pandemic. Here, in Washington we have 4 phases. Phase 1 has the most restrictions and phase 4 is the pandemic is over. Most of Washington made it into phase 2 (ie., small gathering, restaurants, and stores opened with socialing distancing, etc). Then the 4th of July holiday weekend happened, and now, many places are back to phase 1 (ie., mandatory mask (which people seem to ignore), gatherings of 5 (or 10) people, etc). It is interesting how people mistake common sense for infringement of their civil liberties. Of course, the political leadership in the USA seems to be leading the pack with a lack common sense. Transitioning to working from home has been interesting. No small children to worry about. But, my son was taking graduate-level on-line courses on music composition for film and multimedia, my wife was on-line, and I'm trying to work. Bandwidth was an issue. Oh, I almost forgot. I could often watch 2 EPL matches a day. If you do look at one of my patches in a PR, feel free to ping me. I had posted a list of PRs to comp.lang.fortran trying to recruit new contributor. Arjen has taken a baby step, but we could use more eyes.
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:e41da82345fb01c4c2641c979a94a975d15312ab commit r11-2487-ge41da82345fb01c4c2641c979a94a975d15312ab Author: Paul Thomas <pault@gcc.gnu.org> Date: Sun Aug 2 10:35:36 2020 +0100 This patch fixes PR96325. See the explanatory comment in the testcase. 2020-08-02 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/96325 * primary.c (gfc_match_varspec): In the case that a component reference is added to an intrinsic type component, emit the error message in this function. gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: New test. * gfortran.dg/pr91589.f90: Update error message.
(In reply to CVS Commits from comment #16) > The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>: > Paul, I see you got the format just right. I stumbled on that part and then decided to get out of town for sanity. I went up to the mountains and found the official center of the universe (seriously, I know where it is now). In my half of the State here we are in Insanity Phase 1.5 on Steve's scale. Cheers all. ;)
(In reply to CVS Commits from comment #16) > gcc/testsuite/ > PR fortran/96325 > * gfortran.dg/pr96325.f90: New test. The new testcase produces +UNRESOLVED: gfortran.dg/pr96325.f90 -O0 compilation failed to produce executable +UNRESOLVED: gfortran.dg/pr96325.f90 -O1 compilation failed to produce executable +UNRESOLVED: gfortran.dg/pr96325.f90 -O2 compilation failed to produce executable +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -g compilation failed to produce executable +UNRESOLVED: gfortran.dg/pr96325.f90 -Os compilation failed to produce executable everywhere. It cannot be ! { dg-do run } when the compilation is expected to fail.
Thanks - this has been pointed out to me already by Dominique d'Humieres. I'll fix tonight or tomorrow. Paul On Sun, 2 Aug 2020 at 23:46, ro at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 > > Rainer Orth <ro at gcc dot gnu.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |ro at gcc dot gnu.org > > --- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> --- > (In reply to CVS Commits from comment #16) > > > gcc/testsuite/ > > PR fortran/96325 > > * gfortran.dg/pr96325.f90: New test. > > The new testcase produces > > +UNRESOLVED: gfortran.dg/pr96325.f90 -O0 compilation failed to produce > executable > +UNRESOLVED: gfortran.dg/pr96325.f90 -O1 compilation failed to produce > executable > +UNRESOLVED: gfortran.dg/pr96325.f90 -O2 compilation failed to produce > executable > +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -fomit-frame-pointer > -funroll-loops > -fpeel-loops -ftracer -finline-functions compilation failed to produce > executable > +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -g compilation failed to > produce > executable > +UNRESOLVED: gfortran.dg/pr96325.f90 -Os compilation failed to produce > executable > > everywhere. It cannot be > > ! { dg-do run } > > when the compilation is expected to fail. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I got caught out by mime content blocking - trying again. Paul On Mon, 3 Aug 2020 at 09:26, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > Thanks - this has been pointed out to me already by Dominique d'Humieres. > I'll fix tonight or tomorrow. > > Paul > > > On Sun, 2 Aug 2020 at 23:46, ro at gcc dot gnu.org < > gcc-bugzilla@gcc.gnu.org> wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 >> >> Rainer Orth <ro at gcc dot gnu.org> changed: >> >> What |Removed |Added >> >> ---------------------------------------------------------------------------- >> CC| |ro at gcc dot gnu.org >> >> --- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> --- >> (In reply to CVS Commits from comment #16) >> >> > gcc/testsuite/ >> > PR fortran/96325 >> > * gfortran.dg/pr96325.f90: New test. >> >> The new testcase produces >> >> +UNRESOLVED: gfortran.dg/pr96325.f90 -O0 compilation failed to produce >> executable >> +UNRESOLVED: gfortran.dg/pr96325.f90 -O1 compilation failed to produce >> executable >> +UNRESOLVED: gfortran.dg/pr96325.f90 -O2 compilation failed to produce >> executable >> +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -fomit-frame-pointer >> -funroll-loops >> -fpeel-loops -ftracer -finline-functions compilation failed to produce >> executable >> +UNRESOLVED: gfortran.dg/pr96325.f90 -O3 -g compilation failed to >> produce >> executable >> +UNRESOLVED: gfortran.dg/pr96325.f90 -Os compilation failed to produce >> executable >> >> everywhere. It cannot be >> >> ! { dg-do run } >> >> when the compilation is expected to fail. >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein >
*** Bug 96432 has been marked as a duplicate of this bug. ***
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:863de9321813f947018cc60b06ba163ddcfbb5f2 commit r11-2535-g863de9321813f947018cc60b06ba163ddcfbb5f2 Author: Paul Thomas <pault@gcc.gnu.org> Date: Tue Aug 4 07:53:50 2020 +0100 Change testcase for pr96325 from run to compile. 2020-08-04 Paul Thomas <pault@gcc.gnu.org> gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: Change from run to compile.
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:316aa7ad19cd5b2dacba61bd7cc930449108abe5 commit r10-9231-g316aa7ad19cd5b2dacba61bd7cc930449108abe5 Author: Paul Thomas <pault@gcc.gnu.org> Date: Sun Aug 2 10:35:36 2020 +0100 This patch fixes PR96325. See the explanatory comment in the testcase. 2020-08-02 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/96325 * primary.c (gfc_match_varspec): In the case that a component reference is added to an intrinsic type component, emit the error message in this function. gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: New test. * gfortran.dg/pr91589.f90: Update error message. (cherry picked from commit e41da82345fb01c4c2641c979a94a975d15312ab)
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:b2b53f0afceb09d20fe02ac1a014d49075f098e5 commit r10-9232-gb2b53f0afceb09d20fe02ac1a014d49075f098e5 Author: Paul Thomas <pault@gcc.gnu.org> Date: Tue Aug 4 07:53:50 2020 +0100 Change testcase for pr96325 from run to compile. 2020-08-04 Paul Thomas <pault@gcc.gnu.org> gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: Change from run to compile. (cherry picked from commit 863de9321813f947018cc60b06ba163ddcfbb5f2)
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:b66dc7d363d26681113692f75ae9c033c12f3897 commit r9-9160-gb66dc7d363d26681113692f75ae9c033c12f3897 Author: Paul Thomas <pault@gcc.gnu.org> Date: Sun Aug 2 10:35:36 2020 +0100 This patch fixes PR96325. See the explanatory comment in the testcase. 2020-08-02 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/96325 * primary.c (gfc_match_varspec): In the case that a component reference is added to an intrinsic type component, emit the error message in this function. gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: New test. * gfortran.dg/pr91589.f90: Update error message. (cherry picked from commit e41da82345fb01c4c2641c979a94a975d15312ab)
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:4d3d6343903f7ad79f0c70767bd106008fbfc346 commit r9-9161-g4d3d6343903f7ad79f0c70767bd106008fbfc346 Author: Paul Thomas <pault@gcc.gnu.org> Date: Tue Aug 4 07:53:50 2020 +0100 Change testcase for pr96325 from run to compile. 2020-08-04 Paul Thomas <pault@gcc.gnu.org> gcc/testsuite/ PR fortran/96325 * gfortran.dg/pr96325.f90: Change from run to compile. (cherry picked from commit 863de9321813f947018cc60b06ba163ddcfbb5f2)
Closed on 9- thru' 11-branches. Thanks for the report and sorry for the belated fix. Paul