[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #25 from Gabor --- I don't want to distract from the effort, but the code I have is way simpler than the code that has the original issue. I have a single class(*) array argument repeated in a few functions, and no other special things. So it may be easier to debug. It certainly looks like that having multiple functions with these types of arguments in the same module causes the issue. My example starts to work if the 4 functions are split into two modules separately. Which is the work-around I ended up doing (well, I had many more functions, but still getting them into two groups in two modules worked). Gabor
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #24 from Ev Drikos --- The hack outlined in comment #23 had raised an error with coarrays that turns to be an uncovered error: https://groups.google.com/g/comp.lang.fortran/c/E3RGBJZt4ag/m/MTXpOqPgAwAJ In short, the hack has no regressions with gcc-4.8.5 But I am neither a committer, nor I can create draft patches for the code on trunk at the moment. Yet, I'll be glad to go into further details if asked. Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #23 from Ev Drikos --- Created attachment 49841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49841=edit Test Cases Only Hello, I'm wondering whether a quick and dirty hack that would keep derived type data per class array declaration could work, coarrays are excluded at the moment (I know nothing about). The attached file contains only test cases for this PR. The first of them demonstrates what the hack could do. Let's see the vtab names: current vtab name: __class_m_T_1_0a hacked vtab name: __class_m_T_1_0a_b.sub2.m Where 'b' is a class array of type 'T' in the subroutine 'sub2', which in turn is in module 'm'.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #22 from Ev Drikos --- Created attachment 49836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49836=edit module + driver A slightly modified example gives me the impression that some local objects that are class arrays share the same Array Specification, even if they have been declared in a different scope, even they have quite different names and size. But they have been declared with an explicit shape that turns to be common, perhaps accidentally. The Array Specification is retrieved like that: as = IS_CLASS_ARRAY (sym) ? CLASS_DATA (sym)->as : sym->as; Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #21 from Jakub Jelinek --- Ah, missed that this isn't any artificial parm like in C++, so guess the primary question is why the two class array dummy arguments share anything between the two procedures.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #20 from Dominique d'Humieres --- > It's my impression that the code compiles also with -O2 > or -O3, which might be an interim solution until this > bug is fixed. I only get a different ICE: 19 | subroutine fun1(this, a) | ^ internal compiler error: in set_parm_rtl, at cfgexpand.c:1401
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #19 from Jakub Jelinek --- Seems each function has properly its own this PARM_DECL, but the fun2 body refers to the fun1 this PARM_DECL, which is invalid when fun2 is not nested in fun1. This wrong this PARM_DECL reference is added during: #1 0x01909a57 in build1 (code=INDIRECT_REF, type=, node=) at ../../gcc/tree.c:4786 #2 0x00ebcf48 in build1_loc (loc=91200, code=INDIRECT_REF, type=, arg1=) at ../../gcc/tree.h:4382 #3 0x00f01746 in build_fold_indirect_ref_loc (loc=91200, t=) at ../../gcc/fold-const.c:15930 #4 0x00b6c166 in gfc_maybe_dereference_var (sym=0x38228a0, var=, descriptor_only_p=false, is_classarray=false) at ../../gcc/fortran/trans-expr.c:2787 #5 0x00b6c97f in gfc_conv_variable (se=0x7fffd100, expr=0x37c0400) at ../../gcc/fortran/trans-expr.c:2945 #6 0x00b80aa3 in gfc_conv_expr (se=0x7fffd100, expr=0x37c0400) at ../../gcc/fortran/trans-expr.c:8864 #7 0x00b80ba6 in gfc_conv_expr_val (se=0x7fffd100, expr=0x37c0400) at ../../gcc/fortran/trans-expr.c:8909 #8 0x00b80c55 in gfc_conv_expr_type (se=0x7fffd100, expr=0x37c0400, type=) at ../../gcc/fortran/trans-expr.c:8923 #9 0x00b2dceb in gfc_trans_dummy_array_bias (sym=0x3822be0, tmpdesc=, block=0x7fffd430) at ../../gcc/fortran/trans-array.c:6753 #10 0x00b57286 in gfc_trans_deferred_vars (proc_sym=0x3821ac0, block=0x7fffd430) at ../../gcc/fortran/trans-decl.c:4829 #11 0x00b5e212 in gfc_generate_function_code (ns=0x3825570) at ../../gcc/fortran/trans-decl.c:6984 #12 0x00b19f9e in gfc_generate_module_code (ns=0x381c790) at ../../gcc/fortran/trans.c:2319 The proc_sym in the gfc_trans_deferred_vars above is fun2. Already in gfc_trans_deferred_vars' 6638 as = IS_CLASS_ARRAY (sym) ? CLASS_DATA (sym)->as : sym->as; the CLASS_DATA (sym)->as contains: (gdb) p debug_tree (as->upper[0]->symtree->n.sym->backend_decl) unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea216498 fields context reference_to_this chain > unsigned restrict DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea216690> readonly unsigned DI passed-by-reference pr92605.f90:17:17 size unit-size align:64 warn_if_not_align:0 context arg-type chain > i.e. the fun1's this PARM_DECL, even when this is during processing of fun2. I don't know the class code in the fortran FE at all, but as has been said, one can't just use PARM_DECLs of some other function except for nested functions, so perhaps one need to use some magic sym that will translate to the this parameter of the current method, or just detect uses of this symbol from other method of the same class and replace it with the right one, whatever.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek --- #c0 started to ICE with r6-202-gf3b0bb7a560be0f05b09287401a10c4c4b12cfc6
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #17 from Ev Drikos --- Created attachment 49817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49817=edit module + driver (In reply to Dominique d'Humieres from comment #12) > The following test compiles (swapping fun1 and fun2): > ... Hello, It's my impression that the code compiles also with -O2 or -O3, which might be an interim solution until this bug is fixed. Hope this helps, Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Dominique d'Humieres changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #16 from Dominique d'Humieres --- If a set a breakpoint at expr.c:10270, after continuing several times I get * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 frame #0: 0x0001014af237 f951`expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) at expr.c:10270:7 10267 been lowered by this point. */ 10268 if (exp) 10269context = decl_function_context (exp); -> 10270 gcc_assert (!exp 10271 || SCOPE_FILE_SCOPE_P (context) 10272 || context == current_function_decl 10273 || TREE_STATIC (exp) Target 0: (f951) stopped. (lldb) p tree_node* exp (lldb) p context (lldb) c Process 43535 resuming during RTL pass: expand pr92065.f90:23:31: 23 | integer function fun2(this, a) | ^ internal compiler error: in expand_expr_real_1, at expr.c:10270 With the modified program I get * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0001009839b7 f951`expand_expr_real_1(exp=, target=, tmode=E_DImode, modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x, inner_reference_p=) at expr.c:10270:7 10267 been lowered by this point. */ 10268 if (exp) 10269context = decl_function_context (exp); -> 10270 gcc_assert (!exp 10271 || SCOPE_FILE_SCOPE_P (context) 10272 || context == current_function_decl 10273 || TREE_STATIC (exp) Target 0: (f951) stopped. (lldb) c Process 43494 resuming Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 186k ( 8%) phase parsing : 0.01 ( 50%) 0.00 ( 0%) 0.01 ( 0%) 1765k ( 79%) phase opt and generate : 0.01 ( 50%) 0.01 (100%) 39.53 (100%) 284k ( 13%) callgraph construction : 0.00 ( 0%) 0.00 ( 0%) 24.16 ( 61%) 12k ( 1%) parser (global): 0.01 ( 50%) 0.00 ( 0%) 0.01 ( 0%) 1765k ( 79%) expand : 0.01 ( 50%) 0.01 (100%) 15.35 ( 39%) 19k ( 1%) initialize rtl : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 12k ( 1%) verify RTL sharing : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) TOTAL : 0.02 0.01 39.55 2239k
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #14 from Gabor --- Hi All, I am sorry if I hurt anyone’s feelings. My goal was to get things improved for the future. If my dry humor offended you, my apologies. Even if you fixed the bug today, I would still have to find a work-around. My nightly tests fail, the users of our software will not upgrade to the latest gfortran, the super computers keep running old versions, and they are not willing to update. So, why I may look selfish in your eyes, the main goal of reporting that the bug still exists in gfortran 10 was to get things better eventually. I have no time to learn how gcc works and find this bug in it and fix it. One would assume that the person who wrote this part of the compiler could fix it easily given the tiny amount of code that can reproduce the problem. For anyone else it is hard. In the end, I have split my module into two parts and that somehow solved the problem. The smallest code producing the issue had 4 functions. I am attaching it in case anyone actually wants it. I have assumed, apparently incorrectly, that gcc and its part gfortran are maintained by the GNU project and that the GNU project has some business model. gcc seems to thrive. I guess gfortran is not important enough. You should take pride in having a compiler as good as intel, nag and much better than pgi. Cheers, Gabor
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #13 from Thomas Koenig --- (In reply to Gabor from comment #10) > Good to know that gfortran has come to an end. It means, for example, that > i will not rely on the openacc implementation either. Or openmp5. Those two fields are actually seeing a lot of funded development right now, done by Mentor Graphics. OpenMP5 is not yet supported, but this is being worked on. As far as general development is concerned: Like Steve, I am one of the volunteers maintaining the compiler. You write that you're not a compiler writer; well, neither am I, in a professional sense. I am a chemical engineer who very occasionally uses Fortran for his day-time job. I contribute to gfortran mainly for three reasons: a) I like the language b) I like the intellectual challenge and c) I want to give something back to the open source community. People often think that you need to be an exceptionally good programmer to contribute to a compiler. I can testify from first-hand experience that this is not necessary, since I am absolutely certain that I am not exceptionally good :-) If you feel strongly that some bug should be fixed, there are several options available to you. You can convince the organization you work for to fund some bug-fixing. You can try to motivate people to fix this (negative motivation usually does not work), or you can try to fix it yourself. Although there is an entry barrier to doing things to the compiler, it is quite possible to find an entry to this, and it is always possible to ask for advice. A starting point is https://gcc.gnu.org/wiki/GFortranHacking . You will need a general-level knowledge of C for this (technically, the gfortran front end to gcc is written in C++, but it is very close to the common subset of C and C++).
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #12 from Dominique d'Humieres --- The following test compiles (swapping fun1 and fun2): module buggy implicit none type :: bar integer :: x end type bar type :: foo integer :: n contains procedure :: fun1 procedure :: fun2 end type foo contains integer function fun1(this, a) implicit none class(foo) :: this class(bar), intent(in) :: a(this%n) fun1 = a(1)%x end function fun1 subroutine fun2(this, a) implicit none class(foo) :: this class(bar), intent(in) :: a(this%n) end subroutine fun2 end module buggy
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #11 from Steve Kargl --- On Sun, Dec 20, 2020 at 05:24:53AM +, gtoth at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > --- Comment #10 from Gabor --- > Good to know that gfortran has come to an end. It means, for example, that > i will not rely on the openacc implementation either. Or openmp5. Seems you have reading comprehension problems. I never stated that gfortran is coming to an end. I stated that I will no longer submit patches or review patches, because of the abuse spewed by users. Almost all individuals that maintain gfortran are VOLUNTEERS. Abuse from users is causing volunteers to find others things to do with their FREE TIME. > I develop software as part of my work, and when someone reports a bug, my > reaction is to try to fix it, not giving a lecture to the user. I am not a > compiler developer. I am not a compiler developer either. I was a volunteer who gave back his patches to the community. 22% of gfortran/libgfortran bugs fixed in 2019 were by me. Snide, backhanded, comments such as After 17 years of Fortran 2003, one would hope to be able to use it. simply do not motivate a volunteer to work on a bug that does not affect him. > I have interacted with various compiler developer > groups, including Intel, nag and pgi. Not all of them are equally good or > competent or quick, but at least they don't try to push the blame on the > user. No one is blaming you for a bug or reporting a bug. I am reacting to your passive aggressive comment. Yeah, we all would like to "After 17 years of Fortran 2003, ... use it." Guess what? Volunteers fix bugs and implement the features in the Fortran standards in their FREE TIME. Instead of harping on those that give you a gift, get involved and fix a bug in the compiler or pay someone to do it for you. > If you haven't fixed a bug for years, why do you respond to a > complaint about it the same day? PR 92065 was reported on 2019-10-11. That's a little over a year ago. Not sure where you got "years".
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #10 from Gabor --- Good to know that gfortran has come to an end. It means, for example, that i will not rely on the openacc implementation either. Or openmp5. I develop software as part of my work, and when someone reports a bug, my reaction is to try to fix it, not giving a lecture to the user. I am not a compiler developer. I have interacted with various compiler developer groups, including Intel, nag and pgi. Not all of them are equally good or competent or quick, but at least they don't try to push the blame on the user. If you haven't fixed a bug for years, why do you respond to a complaint about it the same day? Gábor On Sat, Dec 19, 2020, 7:02 PM sgk at troutmask dot apl.washington.edu < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > --- Comment #9 from Steve Kargl > --- > On Sat, Dec 19, 2020 at 11:35:24PM +, gtoth at umich dot edu wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > > > > > Apparently this bug was reported years ago, and it was not fixed. There > was no > > suggestion on how to avoid it either. > > > > I am not sure why gfortran is not supported by GNU, as it is used > heavily in > > the computational physics community and gfortran is one of the compilers > (the > > other is ifort) installed on supercomputers around the world. There are > > millions and millions of lines of code depending on Fortran and there > are 10s > > of thousands of scientists and students using these codes. The only hope > to > > adopt new (meaning beyond F77 and F90) features of Fortran by the > community is > > to have compilers that can handle these new features. Why am I wasting > time to > > write a nice piece of code (in this case a general interpolation routine > that > > can handle any type of numbers) if in the end I get a compiler internal > error. > > nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran > is one > > of the MAIN fortran compilers. So now I have to dumb down my code to the > usual > > cut-and-paste style, repetition and so on, because I cannot use > class(*). > > > > So I am frustrated. And maybe my frustration will motivate you to fix the > > problem. > > > > Apparently, you missed the word "volunteer". How much did you > (and others) pay in ifort and nagfor licenses and support > contracts? No one is willing to pay for general maintianence > of gfortran. At best, you may find someone willing to pay for > a specific feature (e.g., ORNL's support for work on openacc). > I've fixed 100s of bugs and implemented some new features for > gfortran. Many of my fixes are for bugs that affected my own > Fortran code. Some are for bugs in areas of the compiler I > know well. I've also reviewed 100s of patches by others. > I do not use the OOP features of Fortran, so I have very little > knowledge about its implementation details. So, your SOL > if you're waiting for me to fix this bug. > > Rants, like yours here, are one of two reasons why I've > stopped contributing to gfortran. I will no longer review > patches, and if I submit a patch, it will be to fix a bug > affecting my code. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #9 from Steve Kargl --- On Sat, Dec 19, 2020 at 11:35:24PM +, gtoth at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > > Apparently this bug was reported years ago, and it was not fixed. There was no > suggestion on how to avoid it either. > > I am not sure why gfortran is not supported by GNU, as it is used heavily in > the computational physics community and gfortran is one of the compilers (the > other is ifort) installed on supercomputers around the world. There are > millions and millions of lines of code depending on Fortran and there are 10s > of thousands of scientists and students using these codes. The only hope to > adopt new (meaning beyond F77 and F90) features of Fortran by the community is > to have compilers that can handle these new features. Why am I wasting time to > write a nice piece of code (in this case a general interpolation routine that > can handle any type of numbers) if in the end I get a compiler internal error. > nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran is > one > of the MAIN fortran compilers. So now I have to dumb down my code to the usual > cut-and-paste style, repetition and so on, because I cannot use class(*). > > So I am frustrated. And maybe my frustration will motivate you to fix the > problem. > Apparently, you missed the word "volunteer". How much did you (and others) pay in ifort and nagfor licenses and support contracts? No one is willing to pay for general maintianence of gfortran. At best, you may find someone willing to pay for a specific feature (e.g., ORNL's support for work on openacc). I've fixed 100s of bugs and implemented some new features for gfortran. Many of my fixes are for bugs that affected my own Fortran code. Some are for bugs in areas of the compiler I know well. I've also reviewed 100s of patches by others. I do not use the OOP features of Fortran, so I have very little knowledge about its implementation details. So, your SOL if you're waiting for me to fix this bug. Rants, like yours here, are one of two reasons why I've stopped contributing to gfortran. I will no longer review patches, and if I submit a patch, it will be to fix a bug affecting my code.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #8 from Gabor --- Dear HTH, Apparently this bug was reported years ago, and it was not fixed. There was no suggestion on how to avoid it either. I am not sure why gfortran is not supported by GNU, as it is used heavily in the computational physics community and gfortran is one of the compilers (the other is ifort) installed on supercomputers around the world. There are millions and millions of lines of code depending on Fortran and there are 10s of thousands of scientists and students using these codes. The only hope to adopt new (meaning beyond F77 and F90) features of Fortran by the community is to have compilers that can handle these new features. Why am I wasting time to write a nice piece of code (in this case a general interpolation routine that can handle any type of numbers) if in the end I get a compiler internal error. nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran is one of the MAIN fortran compilers. So now I have to dumb down my code to the usual cut-and-paste style, repetition and so on, because I cannot use class(*). So I am frustrated. And maybe my frustration will motivate you to fix the problem. Thank you, Gabor > On Dec 19, 2020, at 6:17 PM, kargl at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > kargl at gcc dot gnu.org changed: > > What|Removed |Added > > CC||kargl at gcc dot gnu.org > > --- Comment #7 from kargl at gcc dot gnu.org --- > (In reply to Gabor from comment #6) >> I have the same problem with gfortran 9 and gfortran 10. After 17 years of >> Fortran 2003, one would hope to be able to use it. > > You forgot to attach your patch that fixes this issue. > > gfortran is mostly maintained and written by a dwindling number > of volunteers. Comments like your second sentence above is not > exactly motivating. > > HTH > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Gabor from comment #6) > I have the same problem with gfortran 9 and gfortran 10. After 17 years of > Fortran 2003, one would hope to be able to use it. You forgot to attach your patch that fixes this issue. gfortran is mostly maintained and written by a dwindling number of volunteers. Comments like your second sentence above is not exactly motivating. HTH
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Gabor changed: What|Removed |Added CC||gtoth at umich dot edu --- Comment #6 from Gabor --- I have the same problem with gfortran 9 and gfortran 10. After 17 years of Fortran 2003, one would hope to be able to use it.
