Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > On 2/21/24 22:00, Steve Kargl wrote:
> > > memleak vs ICE. I think I'll take one over the other.
> > > Probably need to free code->expr3 before the copy.
> >
> > Yep.
> >
> > > I tried gfc_replace_expr in an earlier patch. It did not
> > > work.
I tried freeing code->expr3 before assigning the new expression.
That leads to
% gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
pid 69473 comm f951 has trashed its stack, killing
gfortran: internal compiler error: Illegal instruction signal terminated
program f951
If I don't free code->expr3 but simply assign the new
expression from gfc_get_parentheses(), your example
now compiles are executes are expected. It now
allocate_with_source_28.f90. Caveat: I don't know
how to test the CLASS uu.
> > > > - it still fails on the following code, because the traversal
> > > >of the refs is incomplete / wrong:
> > > >
> > > > program foo
> > > > implicit none
> > > > complex :: cmp(3)
> > > > real, pointer :: pp(:)
> > > > class(*), allocatable :: uu(:)
> > > > type t
> > > >real :: re
> > > >real :: im
> > > > end type t
> > > > type u
> > > >type(t) :: tt(3)
> > > > end type u
> > > > type(u) :: cc
> > > >
> > > > cmp = (3.45,6.78)
> > > > cc% tt% re = cmp% re
> > > > cc% tt% im = cmp% im
> > > > allocate (pp, source = cc% tt% im) ! ICE
> > >
> > > cc%tt%im isn't a complex-part-ref, so this seems to
> > > be a different (maybe related) issue. Does the code
> > > compile with 'source = (cc%tt%im)'? If so, perhaps,
> > > detecting a component reference and doing the simply
> > > wrapping with parentheses can be done.
> >
> > Yes, that's why I tried to make up the above example.
> > I think %re and %im are not too special, they work
> > here pretty much like component refs elsewhere.
> >
>
> I see. The %re and %im complex-part-ref correspond to
> ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
> A part-ref for a user-defined type doesn't have an
> INQUIRY_xxx, so we'll need to see if there is a way to
> easily identify, e.g., cc%tt%re from your testcase.
The attach patch uses ref->type == REF_COMPONENT to deal
with the above code.
--
Steve
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..414248fe2e5 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6354,9 +6354,35 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
al = al->next)
vtab_needed = (al->expr->ts.type == BT_CLASS);
+ /* When expr3 is a variable, i.e., a very simple expression, then
+ convert it once here. */
+
gfc_init_se (, NULL);
- /* When expr3 is a variable, i.e., a very simple expression,
- then convert it once here. */
+
+ /* If one has source = z%re or z%im with z a complex array or
+ source = a%b%c where a or b is an array of a derived type, then
+ things can go sideways with the complex-part-refi or part-ref, so
+ wrap the entity in parentheses to force evaluation of an expression.
+ That is, the else-branch in the following if-else-stmt is entered. */
+
+ if (code->expr3->expr_type == EXPR_VARIABLE
+ && code->expr3->ts.type == BT_REAL
+ && code->expr3->ref)
+ {
+ gfc_ref *ref = code->expr3->ref;
+
+ while (ref->next)
+ ref = ref->next;
+
+ if (ref->u.i == INQUIRY_IM || ref->u.i == INQUIRY_RE
+ || ref->type == REF_COMPONENT)
+ {
+ gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+ code->expr3 = gfc_copy_expr (etmp);
+ gfc_free_expr (etmp);
+ }
+ }
+
if (code->expr3->expr_type == EXPR_VARIABLE
|| code->expr3->expr_type == EXPR_ARRAY
|| code->expr3->expr_type == EXPR_CONSTANT)
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
new file mode 100644
index 000..d0f0f3c4a84
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
@@ -0,0 +1,20 @@
+!
+! { dg-do run }
+!
+! fortran/PR114024
+! https://github.com/fujitsu/compiler-test-suite
+! Modified from Fortran/0093/0093_0130.f90
+!
+program foo
+ implicit none
+ complex :: cmp(3)
+ real, allocatable :: xx(:), yy(:), zz(:)
+ cmp = (3., 6.78)
+ allocate(xx, source = cmp%re) ! This caused an ICE.
+ allocate(yy, source = cmp(1:3)%re) ! This caused an ICE.
+ allocate(zz, source = (cmp%re))
+ if (any(xx /= [3., 3., 3.])) stop 1
+ if (any(yy /= [3., 3., 3.])) stop 2
+ if (any(zz /= [3., 3., 3.])) stop 3
+end program foo
+
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
new file mode 100644
index 000..5b167cd
--- /dev/null
+++
Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote: > On 2/21/24 22:00, Steve Kargl wrote: > > Unfortunately, valgrind does not work on AMD FX-8350 cpu. > > Do you mean valgrind does not work at all? > For gcc, you need to configure --enable-valgrind-annotations > to not get bogus warnings. It does not work at all unless one tracks done an obscure patch for valgrind. The FX-8350 has a tbm instruction. Everything on the system would need be compiled with -mno-tbm (or -fno-tbm). % valgrind ./z ... ==88861== Process terminating with default action of signal 4 (SIGILL): dumping core ==88861== Illegal opcode at address 0x4D30D87 ==88861==at 0x4D30D87: ??? (in /lib/libc.so.7) ==88861==by 0x4D213DE: ??? (in /lib/libc.so.7) ==88861==by 0x4D2B935: ??? (in /lib/libc.so.7) ==88861==by 0x4D2C34E: ??? (in /lib/libc.so.7) ==88861==by 0x400AB8C: ??? (in /libexec/ld-elf.so.1) ==88861==by 0x4009828: ??? (in /libexec/ld-elf.so.1) ==88861==by 0x4006AE8: ??? (in /libexec/ld-elf.so.1) > > memleak vs ICE. I think I'll take one over the other. > > Probably need to free code->expr3 before the copy. > > Yep. > > > I tried gfc_replace_expr in an earlier patch. It did not > > work. > > > > > > - it still fails on the following code, because the traversal > > >of the refs is incomplete / wrong: > > > > > > program foo > > > implicit none > > > complex :: cmp(3) > > > real, pointer :: pp(:) > > > class(*), allocatable :: uu(:) > > > type t > > >real :: re > > >real :: im > > > end type t > > > type u > > >type(t) :: tt(3) > > > end type u > > > type(u) :: cc > > > > > > cmp = (3.45,6.78) > > > cc% tt% re = cmp% re > > > cc% tt% im = cmp% im > > > allocate (pp, source = cc% tt% im) ! ICE > > > > cc%tt%im isn't a complex-part-ref, so this seems to > > be a different (maybe related) issue. Does the code > > compile with 'source = (cc%tt%im)'? If so, perhaps, > > detecting a component reference and doing the simply > > wrapping with parentheses can be done. > > Yes, that's why I tried to make up the above example. > I think %re and %im are not too special, they work > here pretty much like component refs elsewhere. > I see. The %re and %im complex-part-ref correspond to ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively. A part-ref for a user-defined type doesn't have an INQUIRY_xxx, so we'll need to see if there is a way to easily identify, e.g., cc%tt%re from your testcase. -- Steve
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 22:00, Steve Kargl wrote: Unfortunately, valgrind does not work on AMD FX-8350 cpu. Do you mean valgrind does not work at all? For gcc, you need to configure --enable-valgrind-annotations to not get bogus warnings. memleak vs ICE. I think I'll take one over the other. Probably need to free code->expr3 before the copy. Yep. I tried gfc_replace_expr in an earlier patch. It did not work. - it still fails on the following code, because the traversal of the refs is incomplete / wrong: program foo implicit none complex :: cmp(3) real, pointer :: pp(:) class(*), allocatable :: uu(:) type t real :: re real :: im end type t type u type(t) :: tt(3) end type u type(u) :: cc cmp = (3.45,6.78) cc% tt% re = cmp% re cc% tt% im = cmp% im allocate (pp, source = cc% tt% im) ! ICE cc%tt%im isn't a complex-part-ref, so this seems to be a different (maybe related) issue. Does the code compile with 'source = (cc%tt%im)'? If so, perhaps, detecting a component reference and doing the simply wrapping with parentheses can be done. Yes, that's why I tried to make up the above example. I think %re and %im are not too special, they work here pretty much like component refs elsewhere. print *, pp allocate (uu, source = cc% tt% im) ! ICE Ditto. Not to mention I know nothing about the implementation of CLASS in gfortran. You can ignore this one for now. It works if one places parens around the source expr as for the other cases. Harald
Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote: > On 2/21/24 20:41, Jerry D wrote: > > On 2/21/24 10:30 AM, Steve Kargl wrote: > > > I have attached a patch to PR114024, see > > > > > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html > > > > > > The patch contains a new testcase and passes regression > > > testing on x86_64-*-freebsd. Could someone castr an eye > > > over the patch and commit it? > > > > > > > Hi Steve, > > > > I looked it over and looks reasonable. I will try to apply it next few > > days and test here. If OK, I will commit. > > > > Jerry > > > > Actually the patch has two issues: > > - a minor one: a new front-end memleak which can be avoided by > using either gfc_replace_expr (see its other uses) > Hint: try valgrind on f951 Unfortunately, valgrind does not work on AMD FX-8350 cpu. memleak vs ICE. I think I'll take one over the other. Probably need to free code->expr3 before the copy. I tried gfc_replace_expr in an earlier patch. It did not work. > - it still fails on the following code, because the traversal > of the refs is incomplete / wrong: > > program foo >implicit none >complex :: cmp(3) >real, pointer :: pp(:) >class(*), allocatable :: uu(:) >type t > real :: re > real :: im >end type t >type u > type(t) :: tt(3) >end type u >type(u) :: cc > >cmp = (3.45,6.78) >cc% tt% re = cmp% re >cc% tt% im = cmp% im >allocate (pp, source = cc% tt% im) ! ICE cc%tt%im isn't a complex-part-ref, so this seems to be a different (maybe related) issue. Does the code compile with 'source = (cc%tt%im)'? If so, perhaps, detecting a component reference and doing the simply wrapping with parentheses can be done. >print *, pp >allocate (uu, source = cc% tt% im) ! ICE Ditto. Not to mention I know nothing about the implementation of CLASS in gfortran. -- Steve
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 12:28 PM, Harald Anlauf wrote: On 2/21/24 20:41, Jerry D wrote: On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? Hi Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry Actually the patch has two issues: - a minor one: a new front-end memleak which can be avoided by using either gfc_replace_expr (see its other uses) Hint: try valgrind on f951 Yes, I am learning to do that. - it still fails on the following code, because the traversal of the refs is incomplete / wrong: program foo implicit none complex :: cmp(3) real, pointer :: pp(:) class(*), allocatable :: uu(:) type t real :: re real :: im end type t type u type(t) :: tt(3) end type u type(u) :: cc cmp = (3.45,6.78) cc% tt% re = cmp% re cc% tt% im = cmp% im allocate (pp, source = cc% tt% im) ! ICE print *, pp allocate (uu, source = cc% tt% im) ! ICE end This still crashes for me for the indicated cases. Harald Good catch. I will hold off until that is figured out. Jerry
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 20:41, Jerry D wrote: On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? Hi Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry Actually the patch has two issues: - a minor one: a new front-end memleak which can be avoided by using either gfc_replace_expr (see its other uses) Hint: try valgrind on f951 - it still fails on the following code, because the traversal of the refs is incomplete / wrong: program foo implicit none complex :: cmp(3) real, pointer :: pp(:) class(*), allocatable :: uu(:) type t real :: re real :: im end type t type u type(t) :: tt(3) end type u type(u) :: cc cmp = (3.45,6.78) cc% tt% re = cmp% re cc% tt% im = cmp% im allocate (pp, source = cc% tt% im) ! ICE print *, pp allocate (uu, source = cc% tt% im) ! ICE end This still crashes for me for the indicated cases. Harald
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? Hi Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry
[PATCH] Fix fortran/PR114024
I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? -- Steve
GFortran for MacBook operating system?
Do you develop Fortran for MacBook systems? Kind regards Mordechai kaun...@live.com kaundam2...@gmail.com kaun...@telkomsa.net https://orcid.org/-0003-0155-5668 C: 27766954243 / 27645788561
