[Bug fortran/103413] New: [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[Bug fortran/103413] New: [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[gscfq@t-online.de]

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

            Bug ID: 103413
           Summary: [10/11/12 Regression] ICE: Invalid expression in
                    gfc_element_size
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started with r10, between 20190630 and 20190728 :


$ cat z1.f90
program p
   type t
      class(*), allocatable :: a
   end type
   type(t) :: x
   allocate (x%a, source=z'1')
end


$ cat z2.f90
program p
   type t
      class(*), allocatable :: a
   end type
   type(t) :: x
   allocate (x%a, mold=z'1')
end


$ cat z3.f90
program p
   type t
      class(*), pointer :: a
   end type
   type(t) :: x
   allocate (x%a, mold=z'1')
end


$ gfortran-12-20211121 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x796be9 gfc_report_diagnostic
        ../../gcc/fortran/error.c:874
0x798757 gfc_internal_error(char const*, ...)
        ../../gcc/fortran/error.c:1494
0x83c8f2 gfc_element_size(gfc_expr*, unsigned long*)
        ../../gcc/fortran/target-memory.c:137
0x778ca2 find_intrinsic_vtab
        ../../gcc/fortran/class.c:2774
0x778ca2 gfc_find_vtab(gfc_typespec*)
        ../../gcc/fortran/class.c:2926
0x80fd4e resolve_allocate_expr
        ../../gcc/fortran/resolve.c:8039
0x80fd4e resolve_allocate_deallocate
        ../../gcc/fortran/resolve.c:8419
0x811c81 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.c:12208
0x813297 resolve_codes
        ../../gcc/fortran/resolve.c:17536
0x81335e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:17571
0x7fb614 resolve_all_program_units
        ../../gcc/fortran/parse.c:6573
0x7fb614 gfc_parse_file()
        ../../gcc/fortran/parse.c:6829
0x848a6f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:216

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-24
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2bf21434a42..971c2fa1dd6 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4447,6 +4447,15 @@ alloc_opt_list:
              goto cleanup;
            }

+         /* A BOZ cannot be a source expression.  */
+         if (ts.type != BT_BOZ)
+           {
+             gfc_error ("boz-literal-constant cannot be a source expression "
+                        "at %L", &tmp->where);
+             goto cleanup;
+           }
+
+
          /* The next 2 conditionals check C631.  */
          if (ts.type != BT_UNKNOWN)
            {
@@ -4484,6 +4493,14 @@ alloc_opt_list:
              goto cleanup;
            }

+         /* A BOZ cannot be a source expression.  */
+         if (ts.type != BT_BOZ)
+           {
+             gfc_error ("boz-literal-constant cannot be a mode expression "
+                        "at %L", &tmp->where);
+             goto cleanup;
+           }
+
          /* Check F08:C637.  */
          if (ts.type != BT_UNKNOWN)
            {

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2bf21434a42..971c2fa1dd6 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -4447,6 +4447,15 @@ alloc_opt_list:
>  	      goto cleanup;
>  	    }
>  
> +	  /* A BOZ cannot be a source expression.  */
> +	  if (ts.type != BT_BOZ)

Got the logic backwards here!  Should be ts.type == BT_BOZ.

> +	    {
> +	      gfc_error ("boz-literal-constant cannot be a source expression "
> +			 "at %L", &tmp->where);
> +	      goto cleanup;
> +	    }
> +
> +
>  	  /* The next 2 conditionals check C631.  */
>  	  if (ts.type != BT_UNKNOWN)
>  	    {
> @@ -4484,6 +4493,14 @@ alloc_opt_list:
>  	      goto cleanup;
>  	    }
>  
> +	  /* A BOZ cannot be a source expression.  */
> +	  if (ts.type != BT_BOZ)

Ditto.

> +	    {
> +	      gfc_error ("boz-literal-constant cannot be a mode expression "
> +			 "at %L", &tmp->where);
> +	      goto cleanup;
> +	    }
> +
>  	  /* Check F08:C637.  */
>  	  if (ts.type != BT_UNKNOWN)
>  	    {

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.4

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
            Summary|[10/11/12 Regression] ICE:  |[10/11/12 Regression] ICE:
                   |Invalid expression in       |Invalid expression in
                   |gfc_element_size            |gfc_element_size since
                   |                            |r10-2083-g8dc63166e0b85954

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r10-2083-g8dc63166e0b85954.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> GCC 10.4 is being released, retargeting bugs to GCC 10.5.

That's a shame.  The patch in comment 1 and the correction
noted in comment 2 where submitted 8 months ago.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to kargl from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > GCC 10.4 is being released, retargeting bugs to GCC 10.5.
> 
> That's a shame.  The patch in comment 1 and the correction
> noted in comment 2 where submitted 8 months ago.

So please test it and send to gcc-fortran mailing list :)

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Jun 29, 2022 at 08:11:01AM +0000, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
> 
> --- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to kargl from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > GCC 10.4 is being released, retargeting bugs to GCC 10.5.
> > 
> > That's a shame.  The patch in comment 1 and the correction
> > noted in comment 2 where submitted 8 months ago.
> 
> So please test it and send to gcc-fortran mailing list :)
> 

I'm not subscribed to fortran@ or gcc-patches@.
Even If I subscribe to a list what good would it
do to send an email?  Someone might glance at 
it.  Then what?  I cannot commit as I don't use
git (an unfortunate consequence of dropping svn)?

I don't add patches to a PR if they do not fix
the problem.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
> I'm not subscribed to fortran@ or gcc-patches@.
> Even If I subscribe to a list what good would it
> do to send an email?  Someone might glance at 
> it.  Then what?  I cannot commit as I don't use
> git (an unfortunate consequence of dropping svn)?

Then somebody can review the patch and commit on your behalf, that's not
problem.
Btw. why do you refuse to learn git, it's much better tool than SVN and for
simple use-case (committing to master) is pretty simple.

> 
> I don't add patches to a PR if they do not fix
> the problem.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Steve,

what do you think about the following patch?  Not yet fully regtested.
It should fix the issue much simpler by checking type compatibility:

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 6050359d521..f4052eb7042 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -5139,6 +5141,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
*ts2)
   bool is_union1 = (ts1->type == BT_UNION);
   bool is_union2 = (ts2->type == BT_UNION);

+  if (ts2->type == BT_BOZ)
+    return (ts1->type == BT_INTEGER || ts1->type == BT_REAL);
+
   if (is_class1
       && ts1->u.derived->components
       && ((ts1->u.derived->attr.is_class

Do you have a testcase that exercises BT_INTEGER and BT_REAL here?
I thought that one of the pathes that reaches gfc_boz2int and gfc_boz2real
might need the above.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> Steve,
> 
> what do you think about the following patch?  Not yet fully regtested.
> It should fix the issue much simpler by checking type compatibility:
> 
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 6050359d521..f4052eb7042 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -5139,6 +5141,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
> *ts2)
>    bool is_union1 = (ts1->type == BT_UNION);
>    bool is_union2 = (ts2->type == BT_UNION);
>  
> +  if (ts2->type == BT_BOZ)
> +    return (ts1->type == BT_INTEGER || ts1->type == BT_REAL);
> +
>    if (is_class1
>        && ts1->u.derived->components
>        && ((ts1->u.derived->attr.is_class
> 
> Do you have a testcase that exercises BT_INTEGER and BT_REAL here?
> I thought that one of the pathes that reaches gfc_boz2int and gfc_boz2real
> might need the above.

Well, a boz is typeless, so it cannot be compatible with any other type.
So, I would assume, you could do 

if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
   return false;

There is a caveat in that Fortran 2023 is going to allow
things like

    real :: x = z'1234'

if gfc_type_compatible is used in simple assignments, gfortran will
need to deal with that.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> Well, a boz is typeless, so it cannot be compatible with any other type.
> So, I would assume, you could do 
> 
> if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
>    return false;

Yes, that's better.

> There is a caveat in that Fortran 2023 is going to allow
> things like
> 
>     real :: x = z'1234'
> 
> if gfc_type_compatible is used in simple assignments, gfortran will
> need to deal with that.

It is currently not used in those cases.

The following is already rejected:

program p
  real :: r
  data r / z'1234' /
  r = z'1234'
  print *, r
end

pr103413-boz.f90:3:18:

    3 |   data r / z'1234' /
      |                  1
Error: BOZ literal constant near (1) cannot be assigned to a REAL variable [see
'-fno-allow-invalid-boz']
pr103413-boz.f90:4:6:

    4 |   r = z'1234'
      |      1
Error: BOZ literal constant at (1) is neither a DATA statement value nor an
actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
'-fno-allow-invalid-boz']

Interestingly, -fno-allow-invalid-boz is not an allowed option...
But even when using -fallow-invalid-boz, which degrades the above to a warning,
I never get to gfc_type_compatible.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Oct 26, 2022 at 06:24:04PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
> 
> --- Comment #11 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #10)
> > Well, a boz is typeless, so it cannot be compatible with any other type.
> > So, I would assume, you could do 
> > 
> > if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
> >    return false;
> 
> Yes, that's better.
> 
> > There is a caveat in that Fortran 2023 is going to allow
> > things like
> > 
> >     real :: x = z'1234'
> > 
> > if gfc_type_compatible is used in simple assignments, gfortran will
> > need to deal with that.
> 
> It is currently not used in those cases.

Hmmm, I wonder if there is duplicate code within gfortran
that re-implements gfc_type_compatible.  If time permits, 
I'll see what comes with a grep of "->type == *->type".


> The following is already rejected:
> 
> program p
>   real :: r
>   data r / z'1234' /
>   r = z'1234'
>   print *, r
> end
> 
> pr103413-boz.f90:3:18:
> 
>     3 |   data r / z'1234' /
>       |                  1
> Error: BOZ literal constant near (1) cannot be assigned to a REAL variable [see
> '-fno-allow-invalid-boz']

F2018

If a data-stmt-constant is a boz-literal-constant, the corresponding
variable shall be of type integer.

F2023 is unchanged.

> pr103413-boz.f90:4:6:
> 
>     4 |   r = z'1234'
>       |      1
> Error: BOZ literal constant at (1) is neither a DATA statement value nor an
> actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
> '-fno-allow-invalid-boz']

This I need to look up in F2023.  The statement may be allowed
only in an initialization expression.

> Interestingly, -fno-allow-invalid-boz is not an allowed option...
> But even when using -fallow-invalid-boz, which degrades the above
> to a warning, I never get to gfc_type_compatible.

The lack of -fno-allow-invalid-boz was intentional.  A BOZ in
an invalid context is an error.  -fallow-invalid-boz allows
that invalid context, but issues a warning.  The only way to
disable the warning is with -w (ie., you disable all warnings).

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[anlauf at gcc dot gnu.org]

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #12)
> > pr103413-boz.f90:4:6:
> > 
> >     4 |   r = z'1234'
> >       |      1
> > Error: BOZ literal constant at (1) is neither a DATA statement value nor an
> > actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see
> > '-fno-allow-invalid-boz']
> 
> This I need to look up in F2023.  The statement may be allowed
> only in an initialization expression.

Given that F2023 is not yet official, I'd say we defer that.
Maybe open a new (Meta-)PR that collects or references the new features.

Oh boy, there's still a lot of F2018 that needs implementing...

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #14 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058384.html

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Oct 26, 2022 at 07:22:47PM +0000, anlauf at gcc dot gnu.org wrote:
>              Status|NEW                         |ASSIGNED
> 
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058384.html
> 

Looks good to me.  I think you can commit.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:f7d28818179247685f3c101f9f2f16366f56309b

commit r13-3513-gf7d28818179247685f3c101f9f2f16366f56309b
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Wed Oct 26 21:00:44 2022 +0200

    Fortran: BOZ literal constants are not compatible to any type [PR103413]

    gcc/fortran/ChangeLog:

            PR fortran/103413
            * symbol.cc (gfc_type_compatible): A boz-literal-constant has no
type
            and thus is not considered compatible to any type.

    gcc/testsuite/ChangeLog:

            PR fortran/103413
            * gfortran.dg/illegal_boz_arg_4.f90: New test.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:9831a5f4843b573bbdb2688bbf2de864b4e8be8b

commit r12-8875-g9831a5f4843b573bbdb2688bbf2de864b4e8be8b
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Wed Oct 26 21:00:44 2022 +0200

    Fortran: BOZ literal constants are not compatible to any type [PR103413]

    gcc/fortran/ChangeLog:

            PR fortran/103413
            * symbol.cc (gfc_type_compatible): A boz-literal-constant has no
type
            and thus is not considered compatible to any type.

    gcc/testsuite/ChangeLog:

            PR fortran/103413
            * gfortran.dg/illegal_boz_arg_4.f90: New test.

    (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:f2298bd50109e5460e8949290b5337ec28310e91

commit r11-10343-gf2298bd50109e5460e8949290b5337ec28310e91
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Wed Oct 26 21:00:44 2022 +0200

    Fortran: BOZ literal constants are not compatible to any type [PR103413]

    gcc/fortran/ChangeLog:

            PR fortran/103413
            * symbol.c (gfc_type_compatible): A boz-literal-constant has no
type
            and thus is not considered compatible to any type.

    gcc/testsuite/ChangeLog:

            PR fortran/103413
            * gfortran.dg/illegal_boz_arg_4.f90: New test.

    (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:3b4c9e0658b13b8db6c7f38242ed270cdb8fc932

commit r10-11063-g3b4c9e0658b13b8db6c7f38242ed270cdb8fc932
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Wed Oct 26 21:00:44 2022 +0200

    Fortran: BOZ literal constants are not compatible to any type [PR103413]

    gcc/fortran/ChangeLog:

            PR fortran/103413
            * symbol.c (gfc_type_compatible): A boz-literal-constant has no
type
            and thus is not considered compatible to any type.

    gcc/testsuite/ChangeLog:

            PR fortran/103413
            * gfortran.dg/illegal_boz_arg_4.f90: New test.

    (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
Fixed on an open branches.  Closing.

Thanks for the report!