[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
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!
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #19 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3b4c9e0658b13b8db6c7f38242ed270cdb8fc932 commit r10-11063-g3b4c9e0658b13b8db6c7f38242ed270cdb8fc932 Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f2298bd50109e5460e8949290b5337ec28310e91 commit r11-10343-gf2298bd50109e5460e8949290b5337ec28310e91 Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #17 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9831a5f4843b573bbdb2688bbf2de864b4e8be8b commit r12-8875-g9831a5f4843b573bbdb2688bbf2de864b4e8be8b Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #16 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f7d28818179247685f3c101f9f2f16366f56309b commit r13-3513-gf7d28818179247685f3c101f9f2f16366f56309b Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #15 from Steve Kargl --- On Wed, Oct 26, 2022 at 07:22:47PM +, 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #12 from Steve Kargl --- On Wed, Oct 26, 2022 at 06:24:04PM +, 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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #8 from Martin Liška --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #7 from Steve Kargl --- On Wed, Jun 29, 2022 at 08:11:01AM +, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 > > --- Comment #6 from Martin Liška --- > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #6 from Martin Liška --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.4|10.5 --- Comment #4 from Jakub Jelinek --- GCC 10.4 is being released, retargeting bugs to GCC 10.5.
