[Bug fortran/92065] [8/9/10 Regression] internal compiler error: in expand_expr_real_1

[Bug fortran/92065] [8/9/10 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
The testcase in comment#0 does not ICE if in function fun2 the
second dummy argument is declared as TYPE instead of CLASS, i.e.

    type (bar), intent(in) :: a(this%n) ! no ICE

instead of

    class(bar), intent(in) :: a(this%n)

Maybe this rings a bell with someone.

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

[gtoth at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Gabor <gtoth at umich dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gtoth at umich dot edu

--- Comment #6 from Gabor <gtoth at umich dot edu> ---
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.

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

[kargl at gcc dot gnu.org]

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

[gtoth at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #8 from Gabor <gtoth at umich dot edu> ---
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 <gcc-bugzilla@gcc.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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Dec 19, 2020 at 11:35:24PM +0000, 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

[gtoth at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #10 from Gabor <gtoth at umich dot edu> ---
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-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
>
> --- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu>
> ---
> On Sat, Dec 19, 2020 at 11:35:24PM +0000, 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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Dec 20, 2020 at 05:24:53AM +0000, gtoth at umich dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
> 
> --- Comment #10 from Gabor <gtoth at umich dot edu> ---
> 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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #13 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(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

[gtoth at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #14 from Gabor <gtoth at umich dot edu> ---
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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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: 0x00000001014af237 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)
   10269                context = 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: 0x00000001009839b7 f951`expand_expr_real_1(exp=<unavailable>,
target=<unavailable>, tmode=E_DImode, modifier=EXPAND_CONST_ADDRESS,
alt_rtl=0x0000000000000000, inner_reference_p=<unavailable>) at expr.c:10270:7
   10267                 been lowered by this point.  */
   10268              if (exp)
   10269                context = 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

[drikosev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Ev Drikos <drikosev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drikosev at gmail dot com

--- Comment #17 from Ev Drikos <drikosev at gmail dot com> ---
Created attachment 49817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49817&action=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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#c0 started to ICE with r6-202-gf3b0bb7a560be0f05b09287401a10c4c4b12cfc6

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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  0x0000000001909a57 in build1 (code=INDIRECT_REF, type=<record_type
0x7fffea216498 __class_buggy_Foo_t>, node=<parm_decl 0x7fffea203700 this>)
    at ../../gcc/tree.c:4786
#2  0x0000000000ebcf48 in build1_loc (loc=91200, code=INDIRECT_REF,
type=<record_type 0x7fffea216498 __class_buggy_Foo_t>, 
    arg1=<parm_decl 0x7fffea203700 this>) at ../../gcc/tree.h:4382
#3  0x0000000000f01746 in build_fold_indirect_ref_loc (loc=91200, t=<parm_decl
0x7fffea203700 this>) at ../../gcc/fold-const.c:15930
#4  0x0000000000b6c166 in gfc_maybe_dereference_var (sym=0x38228a0,
var=<parm_decl 0x7fffea203700 this>, descriptor_only_p=false, 
    is_classarray=false) at ../../gcc/fortran/trans-expr.c:2787
#5  0x0000000000b6c97f in gfc_conv_variable (se=0x7fffffffd100, expr=0x37c0400)
at ../../gcc/fortran/trans-expr.c:2945
#6  0x0000000000b80aa3 in gfc_conv_expr (se=0x7fffffffd100, expr=0x37c0400) at
../../gcc/fortran/trans-expr.c:8864
#7  0x0000000000b80ba6 in gfc_conv_expr_val (se=0x7fffffffd100, expr=0x37c0400)
at ../../gcc/fortran/trans-expr.c:8909
#8  0x0000000000b80c55 in gfc_conv_expr_type (se=0x7fffffffd100,
expr=0x37c0400, type=<integer_type 0x7fffea056738 integer(kind=8)>)
    at ../../gcc/fortran/trans-expr.c:8923
#9  0x0000000000b2dceb in gfc_trans_dummy_array_bias (sym=0x3822be0,
tmpdesc=<var_decl 0x7ffff7fcae10 a.0>, block=0x7fffffffd430)
    at ../../gcc/fortran/trans-array.c:6753
#10 0x0000000000b57286 in gfc_trans_deferred_vars (proc_sym=0x3821ac0,
block=0x7fffffffd430) at ../../gcc/fortran/trans-decl.c:4829
#11 0x0000000000b5e212 in gfc_generate_function_code (ns=0x3825570) at
../../gcc/fortran/trans-decl.c:6984
#12 0x0000000000b19f9e 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)
 <parm_decl 0x7fffea203700 this
    type <reference_type 0x7fffea216690
        type <record_type 0x7fffea216498 __class_buggy_Foo_t type_4 TI
            size <integer_cst 0x7fffea041c00 constant 128>
            unit-size <integer_cst 0x7fffea041c18 constant 16>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea216498 fields <field_decl 0x7fffea215da8 _data> context <namespace_decl
0x7fffea2151c8 buggy>
            reference_to_this <reference_type 0x7fffea2165e8> chain <type_decl
0x7fffea215ed8 D.3955>>
        unsigned restrict DI
        size <integer_cst 0x7fffea041bb8 constant 64>
        unit-size <integer_cst 0x7fffea041bd0 constant 8>
        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
<integer_cst 0x7fffea041bb8 64> unit-size <integer_cst 0x7fffea041bd0 8>
    align:64 warn_if_not_align:0 context <function_decl 0x7fffea214700 fun1>
arg-type <reference_type 0x7fffea216690> chain <parm_decl 0x7fffea203780 a>>
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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[drikosev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #22 from Ev Drikos <drikosev at gmail dot com> ---
Created attachment 49836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49836&action=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

[drikosev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #23 from Ev Drikos <drikosev at gmail dot com> ---
Created attachment 49841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49841&action=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

[drikosev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #24 from Ev Drikos <drikosev at gmail dot com> ---
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

[gtoth at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #25 from Gabor <gtoth at umich dot edu> ---
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] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #27 from anlauf at gcc dot gnu.org ---
The code seems to compile with today's trunk, but still fails with 11-branch.
Could one of Paul's recent commits have fixed this?  If so, a backport might
be nice.

[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
So let's ask people to bisect what fixed it.

[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e fixed it.

[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #30 from anlauf at gcc dot gnu.org ---
Adding Paul.

[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug fortran/92065] [9/10/11 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #32 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #29)
> r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e fixed it.

This fix has been backported to all open branches.

I verified that the ICE is now gone for the testcae in comment#0.
Closing this PR.  Please reopen if there is something that has been missed.