Re: [Patch, Fortran] 2/3 Refactor locations where _vptr is (re)set.
Hi Paul, thanks for the review. I have removed the commented assert and committed as gcc-15-1704-gaa3599a10ca What about your pr59104 patch? It is living happily in my dev-branch and making no problems. Thanks again and regards, Andre On Thu, 27 Jun 2024 07:29:40 +0100 Paul Richard Thomas wrote: > Hi Andre, > > Thanks for resending the patches. I fear that daytime work and visitors > have taken my attention the last days - hence the delay in reviewing, for > which I apoloise, > > The patches do what they are advertised to do, without regressions on my > side. I like gfc_class_set_vptr. Please remove the commented out assert, > unless you intend to deploy it. > > OK for mainline. > > Thanks for the patches. > > Regards > > Paul > > > On Fri, 21 Jun 2024 at 07:39, Andre Vehreschild wrote: > > > Hi Paul, > > > > I am sorry for the delay. I am fighting with PR96992, where Harald finds > > more > > and more issues. I think I am approaching that one wrongly. We will see. > > > > Anyway, please find attached updated version of the 2/3 and 3/3 patches, > > which > > apply cleanly onto master at 1f974c3a24b76e25a2b7f31a6c7f4aee93a9eaab . > > > > Hope that helps and thanks in advance for looking at the patches. > > > > Regards, > > Andre > > > > PS. I have attached them in plain text and as archive to prevent mailers > > from > > corrupting them. > > > > On Thu, 20 Jun 2024 07:42:31 +0100 > > Paul Richard Thomas wrote: > > > > > Hi Andre, > > > > > > Both this patch and 3/3 are corrupt according to git apply: > > > [pault@pc30 gcc]$ git apply --ignore-space-change --ignore-whitespace < > > > ~/prs/andre/u*.patch > > > error: corrupt patch at line 45 > > > [pault@pc30 gcc]$ git apply --ignore-space-change --ignore-whitespace < > > > ~/prs/andre/i*.patch > > > error: corrupt patch at line 36 > > > > > > I tried messing with the offending lines, to no avail. I can apply them > > by > > > hand or, perhaps, you could supply me with clean patches? > > > > > > The patches look OK but I want to check the code that they generate. > > > > > > Cheers > > > > > > Paul > > > > > > > > > On Tue, 11 Jun 2024 at 13:57, Andre Vehreschild wrote: > > > > > > > Hi all, > > > > > > > > this patch refactors most of the locations where the _vptr of a class > > data > > > > type > > > > is reset. The code was inconsistent in most of the locations. The goal > > of > > > > using > > > > only one routine for setting the _vptr is to be able to later modify it > > > > more > > > > easily. > > > > > > > > The ultimate goal being that every time one assigns to a class data > > type a > > > > consistent way is used to prevent forgetting the corner cases. So this > > is > > > > just a > > > > small step in this direction. I think it is worth to simplify the code > > to > > > > something consistent to reduce maintenance efforts anyhow. > > > > > > > > Regtested ok on x86_64 Fedora 39. Ok for mainline? > > > > > > > > Regards, > > > > Andre > > > > -- > > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > > > > > -- > > Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen > > Tel.: +49 241 9291018 * Email: ve...@gmx.de > > -- Andre Vehreschild * Email: vehre ad gmx dot de
[PATCH] Fortran: fix ALLOCATE with SOURCE of deferred character length [PR114019]
Dear all,
the attached patch fixes an ICE occuring for ALLOCATE with SOURCE
(or MOLD) of deferred character length in the scalar case, which
looked obscure because the ICE disappears at -O1 and higher.
The dump tree suggests that it is a wrong decl for the temporary
source that was e.g.
character(kind=1) source.2[1:];
whereas I had expected
character(kind=1)[1:] * source.2;
and which we now get after the patch. Or am I missing something?
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4d12f6d0cf63ea6a2deb5398e6478dde114e76b8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Jun 2024 21:44:06 +0200
Subject: [PATCH] Fortran: fix ALLOCATE with SOURCE of deferred character
length [PR114019]
gcc/fortran/ChangeLog:
PR fortran/114019
* trans-stmt.cc (gfc_trans_allocate): Fix handling of case of
scalar character expression being used for SOURCE.
gcc/testsuite/ChangeLog:
PR fortran/114019
* gfortran.dg/allocate_with_source_33.f90: New test.
---
gcc/fortran/trans-stmt.cc | 5 +-
.../gfortran.dg/allocate_with_source_33.f90 | 53 +++
2 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/allocate_with_source_33.f90
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 93b633e212e..60275e18867 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6464,7 +6464,10 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
else if (se.expr != NULL_TREE && temp_var_needed)
{
tree var, desc;
- tmp = GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr)) || is_coarray ?
+ tmp = (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr))
+ || is_coarray
+ || (code->expr3->ts.type == BT_CHARACTER
+ && code->expr3->rank == 0)) ?
se.expr
: build_fold_indirect_ref_loc (input_location, se.expr);
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_33.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_33.f90
new file mode 100644
index 000..7b1a26c464c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_33.f90
@@ -0,0 +1,53 @@
+! { dg-do compile }
+! { dg-options "-O0" }
+!
+! PR fortran/114019 - allocation with source of deferred character length
+
+subroutine s
+ implicit none
+ character(1) :: w = "4"
+ character(*), parameter :: str = "123"
+ character(5), pointer :: chr_pointer1
+ character(:), pointer :: chr_pointer2
+ character(:), pointer :: chr_ptr_arr(:)
+ character(5), allocatable :: chr_alloc1
+ character(:), allocatable :: chr_alloc2
+ character(:), allocatable :: chr_all_arr(:)
+ allocate (chr_pointer1, source=w// str//w)
+ allocate (chr_pointer2, source=w// str//w)
+ allocate (chr_ptr_arr, source=w//[str//w])
+ allocate (chr_alloc1, source=w// str//w)
+ allocate (chr_alloc2, source=w// str//w)
+ allocate (chr_all_arr, source=w//[str//w])
+ allocate (chr_pointer1, mold =w// str//w)
+ allocate (chr_pointer2, mold =w// str//w)
+ allocate (chr_ptr_arr, mold =w//[str//w])
+ allocate (chr_alloc1, mold =w// str//w)
+ allocate (chr_alloc2, mold =w// str//w)
+ allocate (chr_all_arr, mold =w//[str//w])
+end
+
+subroutine s2
+ implicit none
+ integer, parameter :: ck=4
+ character(kind=ck,len=1) :: w = ck_"4"
+ character(kind=ck,len=*), parameter :: str = ck_"123"
+ character(kind=ck,len=5), pointer :: chr_pointer1
+ character(kind=ck,len=:), pointer :: chr_pointer2
+ character(kind=ck,len=:), pointer :: chr_ptr_arr(:)
+ character(kind=ck,len=5), allocatable :: chr_alloc1
+ character(kind=ck,len=:), allocatable :: chr_alloc2
+ character(kind=ck,len=:), allocatable :: chr_all_arr(:)
+ allocate (chr_pointer1, source=w// str//w)
+ allocate (chr_pointer2, source=w// str//w)
+ allocate (chr_ptr_arr, source=w//[str//w])
+ allocate (chr_alloc1, source=w// str//w)
+ allocate (chr_alloc2, source=w// str//w)
+ allocate (chr_all_arr, source=w//[str//w])
+ allocate (chr_pointer1, mold =w// str//w)
+ allocate (chr_pointer2, mold =w// str//w)
+ allocate (chr_ptr_arr, mold =w//[str//w])
+ allocate (chr_alloc1, mold =w// str//w)
+ allocate (chr_alloc2, mold =w// str//w)
+ allocate (chr_all_arr, mold =w//[str//w])
+end
--
2.35.3
Re: [PATCH] Fortran: fix ALLOCATE with SOURCE of deferred character length [PR114019]
On Fri, Jun 28, 2024 at 10:00:53PM +0200, Harald Anlauf wrote: > > the attached patch fixes an ICE occuring for ALLOCATE with SOURCE > (or MOLD) of deferred character length in the scalar case, which > looked obscure because the ICE disappears at -O1 and higher. > > The dump tree suggests that it is a wrong decl for the temporary > source that was e.g. > > character(kind=1) source.2[1:]; > > whereas I had expected > > character(kind=1)[1:] * source.2; > > and which we now get after the patch. Or am I missing something? > > Regtested on x86_64-pc-linux-gnu. OK for mainline? I don't think you're missing anything. We've a number of bugs were one needs to distinguish between various declarations: character(len=2), allocatable :: a character(len=:), allocatable :: a(2) character(len=:), allocatable :: a(:) I can certain imagine you've fixed another (corner) case that was originally missed. OK to commit. Thanks for the patch. -- Steve
unsigned type
FYI, For those that do not follow J3, their meeting just finished this week. One noteworthy paper that passed was 24-166.txt, "A modest proposal for adding an UNSIGNED type to Fortran". The paper appears to have been author by Thomas (tkoening@). Big "Thank You" to Thomas. I have wanted an unsigned type for a very long time. -- Steve
