[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 --- Comment #5 from Paul Thomas --- (In reply to Tobias Burnus from comment #4) > (In reply to Dominique d'Humieres from comment #1) > > Reduced test > > While -fsanitize=address,undefined does not find anything on > x86_64-gnu-linux, I do see with valgrind: > > ==98347== Invalid write of size 8 > ==98347==at 0x40397E: test_t1_ (ijd.f90:43) > ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) > ==98347==by 0x403A85: main (ijd.f90:61) > ==98347== Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd > ==98347==at 0x483DFAF: realloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==98347==by 0x402A6D: test_t1_ (ijd.f90:40) > ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) > ==98347==by 0x403A85: main (ijd.f90:61) > > That's: > x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] > y = x > x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12 > x = realloc_t1 (x) > x = x(3:1:-1) + y > x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of > size 8 > > Looking at the Fortran code, > x and y have the dynamic type T2 until 'realloc_t1', which turns this into > the dynamic type T1. > > In the last line (line 43), the dynamic type changes again to T2. > > In terms of memory usage: 3*8bytes before the first realloc_t1 call, then > 3*4bytes and for the last line again 3*8bytes. > > * * * > > It seems as if the reallocation does not work properly if the dynamic type > changes – at least not if the required size increased in the assignment. > (The valgrind message implies that shrinking did work in line 40.) I am unable to see why this is happening. The valgrind complaints go away if a different array size is assigned before the changes in type. For some reason, it seems that the vptr->size is not being read correctly or is never set. Paul
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 50368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50368&action=edit A fix and more for the PR The chunk: @@ -10274,23 +10309,10 @@ gfc_alloc_allocatable_for_assignment fixes the PR. The rest gets rid of all(?) array references of class objects since the casting was always a problem. Cheers Paul
[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 50386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50386&action=edit Fix for the PR Juergen, Thanks for the report and the reduction. r11-6253-gce8dcc9105cbd404 exposed at error in gfc_trans_allocate. What is manifestly an initialization assignment was not being flagged as such. I will commit as obvious later on today. Regards Paul
[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #14 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #13)
> I confirm that with that patch our code compiles again, however, more or
> less all functionality fails because of runtime errors about
> Fortran runtime error: Pointer actual argument '' is not
> associated.
> Not sure whether this is related. Shall I open another PR?
> Working on a reproducer for that problem.
Please work on a reproducer. I cannot quite see that the new problem is related
but keep this PR open for now.
The test below works, so the correct functionality of allocate is retained.
Your original reproducer no longer ICEs and gives the correct runtime error.
Cheers
Paul
! { dg-do compile }
! { dg-options "-fcheck=mem" }
!
! Test the fix for PR99545, in which the allocate statements caused an ICE.
!
! Contributed by Juergen Reuter
!
module commands
implicit none
! private
type, abstract :: range_t
integer :: step_mode = 0
integer :: n_step = 0
end type range_t
type, extends (range_t) :: range_int_t
integer :: i_step = 1
end type range_int_t
type, extends (range_t) :: range_real_t
real :: lr_step = 2.0
end type range_real_t
type :: cmd_scan_t
! private
class(range_t), dimension(:), allocatable :: range
contains
procedure :: compile => cmd_scan_compile
end type cmd_scan_t
contains
subroutine cmd_scan_compile (cmd, sw)
class(cmd_scan_t), intent(inout) :: cmd
integer :: sw
if (allocated (cmd%range)) deallocate (cmd%range)
if (sw .eq. 1) then
allocate (range_int_t :: cmd%range (3))
else
allocate (range_real_t :: cmd%range (3))
end if
end subroutine cmd_scan_compile
end module commands
use commands
class(cmd_scan_t), allocatable :: x
integer :: i
allocate (x)
do i = 1, 2
call x%compile (i)
select type (y => x%range)
type is (range_int_t)
print *, y%i_step
type is (range_real_t)
print *, y%lr_step
end select
end do
end
[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Paul Thomas --- Closed as fixed on all three branches. Paul
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #8 from Paul Thomas --- (In reply to Jürgen Reuter from comment #6) > Actually, the last example missed a line that I overeagerly deleted too > much. This one is the correct reproducer: > module m > implicit none > private > public :: m_t > type :: m_t > private > end type m_t > end module m > > module m2_testbed > use m > implicit none > private > public :: prepare_m2 > procedure (prepare_m2_proc), pointer :: prepare_m2 => null () > > abstract interface > subroutine prepare_m2_proc (m2) >import >class(m_t), intent(inout), pointer :: m2 > end subroutine prepare_m2_proc > end interface > > end module m2_testbed > > module a > use m > use m2_testbed, only: prepare_m2 > implicit none > private > public :: a_1 > > contains > > subroutine a_1 () > class(m_t), pointer :: mm > mm => null () > call prepare_m2 (mm) > end subroutine a_1 > > end module a > > > module m2 > use m > implicit none > private > public :: m2_t > > type, extends (m_t) :: m2_t > private >contains > procedure :: read => m2_read > end type m2_t > contains > > subroutine m2_read (mm) > class(m2_t), intent(out), target :: mm > end subroutine m2_read > end module m2 > > program main > use m2_testbed > use a, only: a_1 > implicit none > prepare_m2 => prepare_whizard_m2 > call a_1 () > > contains > > subroutine prepare_whizard_m2 (mm) > use m > use m2 > class(m_t), intent(inout), pointer :: mm > if (.not. associated (mm)) allocate (m2_t :: mm) > select type (mm) > type is (m2_t) >call mm%read () > end select > end subroutine prepare_whizard_m2 > end program main Hi Juergen, I still cannot reproduce the problem. In fact, the runtime error message does not appear in the tree dump. Best regards Paul
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-16 Ever confirmed|0 |1 --- Comment #11 from Paul Thomas --- I took my build directory down to bedrock and recompiled. I see the problem now. I'm onto it :-) Paul
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #12 from Paul Thomas --- Created attachment 50397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50397&action=edit Fix for the PR This regtests OK. The problem seems to have been caused by the fix for PR99112. Cheers Paul
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #28 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #27)
> Created attachment 50432 [details]
> reproducer, down to 6800 lines
Hi Juergen,
Stop! Yesterday's final is just fine. The problem is connected with the logic
selecting the runtime error. The code for line 483 ends with
D.5856 = model->_vptr->get_par_data_ptr (&model.110,
D.5855);
if ((character(kind=1)[0:][1:1] * restrict)
D.5855->chars.data != 0B)
{
__builtin_free ((void *) D.5855->chars.data);
(character(kind=1)[0:][1:1] * restrict)
D.5855->chars.data = 0B;
}
if ((integer(kind=8)) (D.5856._data == 0B))
{
_gfortran_runtime_error_at (&"At line 483 of file
models.f90"[1]{lb: 1 sz: 1}, &"Proc-pointer actual argument \'model\' is not
associated"[1]{lb: 1 sz: 1});
}
field_data_set (&class.109, 0B, 0B, 0B, 0B, 0B, 0B, 0B,
0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, &D.5856, 0B,
0B, 0B);
}
The _data field of D.5856 is the result of the call to 'get_par_data_ptr' not
the procedure pointer itself. The result is:
class(modelpar_data_t), pointer :: ptr and the formal argument is:
class(modelpar_data_t), intent(in), pointer, optional :: mass_data
So the call is perfectly proper. The trouble is that the attributes of the
proc_pointer result are not being used.
I am about to start a gdb session :-)
Paul
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #30 from Paul Thomas ---
Created attachment 50442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50442&action=edit
Patch that "fixes" all versions of the problem.. so far :-)
Hi Juergen,
I think that this one does the job... it is even correct and regtests OK;-)
I found that the gdb session was a miserable afair that didn't help at all
because of the change in dwarf versions. I would up reducing the testcase to
what you will find below. Please excuse my mutilation of Whizard!
The chunk of whizard that you provided throws up all sorts of memories. In the
1970's I used to go up to Caltech every Wednesday for Feynman and Gell-mann
seminars. I was around for the earliest days of partons and the realisation
that quarks might even be real.
Paul
module model_data
type :: model_data_t
type(modelpar_real_t), dimension(:), pointer :: par_real => null ()
contains
procedure :: get_par_data_ptr => model_data_get_par_data_ptr_name
procedure :: set => field_data_set
end type model_data_t
type :: modelpar_real_t
character (4) :: name
real(4) :: value
end type modelpar_real_t
type(modelpar_real_t), target :: names(2) = [modelpar_real_t("foo ", 1), &
modelpar_real_t("bar ", 2)]
contains
function model_data_get_par_data_ptr_name (model, name) result (ptr)
class(model_data_t), intent(in) :: model
character (*), intent(in) :: name
class(modelpar_real_t), pointer :: ptr
integer :: i
ptr => null ()
do i = 1, size (model%par_real)
if (model%par_real(i)%name == name) ptr => model%par_real(i)
end do
end function model_data_get_par_data_ptr_name
subroutine field_data_set (this, ptr)
class(model_data_t), intent(inout) :: this
class(modelpar_real_t), intent(in), pointer :: ptr
if (associated (ptr)) then
print *, "'ptr%value' = ", ptr%value
else
print *, "'ptr' not associated in 'field_data_set'"
end if
end subroutine
end module model_data
use model_data
class(model_data_t), allocatable :: model
class(modelpar_real_t), pointer :: name_ptr
allocate (model_data_t :: model)
model%par_real => names
! name_ptr => model%get_par_data_ptr ("bar ")
! call field_data_set (model, name_ptr)
! call field_data_set (model, model%get_par_data_ptr ("bar "))
call model%set (model%get_par_data_ptr ("bar "))
call model%set (model%get_par_data_ptr ("tea "))
end
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #33 from Paul Thomas --- (In reply to Jürgen Reuter from comment #32) > Ready for merge? Hi Juergen, Daytime work intervened. I will submit to the list today. Thanks for all your support BTW. Paul
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 --- Comment #2 from Paul Thomas --- (In reply to Martin Liška from comment #1) > Started with r11-7188-gff6903288d96aa1d. Thanks, Gerhard and Martin. Have you ever tried to put a tent up in a storm? Sometimes maintaining gfortran feels just like that :-) Paul
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 50494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50494&action=edit Fix for the PR The fix is trivial - gfortran now gives the correct error. 15 | call y%s |1 Error: Actual argument to ‘x’ at (1) must be a coarray Paul
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 --- Comment #6 from Paul Thomas --- (In reply to G. Steinmetz from comment #4) > > Have you ever tried to put a tent up in a storm? > ... geez, how difficult and lengthy ... > > The number of bug reports is admittedly increasing, > but the number of still unknown bugs is decreasing, isn't it? > > And my impression is indeed that the number of > unfixed/unknown bugs in gfortran is now roughly limited > to huge(1_alpha), with alpha=~1.5 ;-) > > The bug reproduction rate is likely less than one :-) The only way to deal with it is a complete lockdown of gfortran for six months. If nobody uses it, the number of bugs will surely drop. Then the roadmap out of lockdown should start with only F95 being allowed, then six months later F2003 and so on. If at any stage the R number goes above unity, we revert one step in the roadmap.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 --- Comment #11 from Paul Thomas --- The patch was posted at https://gcc.gnu.org/pipermail/fortran/2021-April/055923.html I'll ping it. Thanks Richard. Paul
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- (In reply to José Rui Faustino de Sousa from comment #1) > Patch posted > > https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html Hi Jose, Please take a look at PR98534. I think that you need to adjust your patch a little bit to take account of unlimited polymorphic entities with character dynamic type. I agree that it is a bit of a corner case but it is as well that your patch be complete. I will remove myself as the assignee. Best regards Paul
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 Paul Thomas changed: What|Removed |Added Assignee|pault at gcc dot gnu.org |unassigned at gcc dot gnu.org CC||burnus at gcc dot gnu.org --- Comment #4 from Paul Thomas --- This needs to be incorporated into the fix for PR100027. I hope that Jose takes this PR over :-) Paul
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #5 from Paul Thomas --- This needs to be incorporated into the fix for PR100027. I hope that Jose takes this PR over :-) Paul
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2021-04-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Paul Thomas --- Hi Xiao, Thank you for this report. I admit that the implementation of PDTs in gfortran is broken. I didn't realise quite how broken it is:-( Making 'obj' allocatable and allocating it produces the expected result. I had planned that once gcc-11 is released, I would turn my attention to PDTs. This one, I suspect, is such a low hanging fruit, that I will give it attention now. Best regards Paul
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 --- Comment #2 from Paul Thomas --- Created attachment 50628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50628&action=edit Fix for the PR As I thought, the fix is trivial. Paul
[Bug fortran/84119] Type parameter inquiry for PDT returns array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84119 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 50636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50636&action=edit Fix for the PR Sorry for the wait. Your analysis is completely correct. Thanks for pointing it out. The attached will be submitted to the fortran list in a few minutes. It regression tests OK. Paul
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #36 from Paul Thomas --- Created attachment 49412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49412&action=edit An updated patch The patch has been evolving... slowly. I found that dependency_57.f90 segfaulted in runtime so I have fixed that. I believe that I know how to resolve Tobias's query. I hope to submit a complete patch in the coming days. Paul
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #37 from Paul Thomas ---
(In reply to Paul Thomas from comment #36)
> Created attachment 49412 [details]
> An updated patch
>
> The patch has been evolving... slowly.
>
> I found that dependency_57.f90 segfaulted in runtime so I have fixed that.
>
> I believe that I know how to resolve Tobias's query. I hope to submit a
> complete patch in the coming days.
>
> Paul
Actually, dependency_5[6,7].f90 are not fixed because the temporaries generated
by the dependencies take their size and type from the class container. For
dependency_56.f90:
D.4055 = f (&class.11);
D.4056 = D.4055._data.dim[0].ubound - D.4055._data.dim[0].lbound;
typedef struct __class__STAR_1_0a [0:];
atmp.12.dtype = {.elem_len=80, .rank=1, .type=7}; /* ! */
gfc_conv_loop_setup needs to use the mechanism for dealing with class
temporaries in gfc_trans_create_temp_array by using the size of the dynamic
type.
Paul
[Bug fortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- I presume that this one can be closed then? Paul
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- This is not a regression IMHO since the inquiry reference feature (ie. ...%re) was introduced by the commit reference in comment 1. That said, it does remove the syntax error for the non-existent feature with an ICE. Paul
[Bug fortran/98016] Host association problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|WAITING |NEW --- Comment #6 from Paul Thomas --- Created attachment 49645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49645&action=edit Fix for the PR This fix is rather different to Steve's. It exploits the existing mechanism for formal arguments. In this context, the function result is equivalent to formal arguments. It even regtests OK :-) Unless there are objections, I will commit as 'obvious' after I fix the last of the nits with PR83118 or, at least, towards the end of the week. Cheers Paul
[Bug fortran/98016] Host association problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 --- Comment #8 from Paul Thomas --- (In reply to Ev Drikos from comment #7) > Created attachment 49659 [details] > attachment for pr98016-07 > > (In reply to Paul Thomas from comment #6) > > Created attachment 49645 [details] > > Fix for the PR > > > > Unless there are objections, ... > > Not an objection, rather just an observation: > > 1. This code is inside "resolve_symbol" and the >following double declaration seems redundant: > >bool saved_specification_expr > >The reason I'm mentioning it is that I debugged >the example with gcc-4.8 and the debugger makes >this call: > >gfc_resolve_array_spec (sym->as, check_constant) > >So, the declaration below could be at the top of >the function declarations like the code below Hi There, The multiple declarations (5 in resolve.c) come about because of the possibility of rather torturous recursion paths. I guess that we could replace the boolean with a counter but this doesn't seem to be much of an improvement. I am just now preparing for a commit this evening. Thanks for the comment. Paul
[Bug fortran/98016] Host association problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on master. Closing. Thanks for posting it Juergen. Paul
[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 Paul Thomas changed: What|Removed |Added Status|NEW |WAITING CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- (In reply to Martin Liška from comment #1) > Confirmed with valgrind. At least as old as 4.9.0. Hi, >From a quick perusal of the standard, I find in F2003 16.4.2.1: "Unless a pointer is initialized (explicitly or by default), it has an initial association status of undefined. A pointer may be initialized to have an association status of disassociated". In your testcase, the status of b%b is undefined and so the compiler can do anything it wants with it, including segfaulting. I think therefore that you should initialize the derived types in your application as follows: type t1 real, dimension(:), pointer :: a => NULL () contains final :: t1f end type type, extends(t1) :: t2 real, dimension(:), pointer :: b => NULL () contains final :: t2f end type This clears the valgrind error "Conditional jump or move depends on uninitialised value(s)". Also the finalization is invoked so that the programme completes with zero memory allocation, To my surprise (probably due to standard ignorance), leaving the declared type declarations as you have them, and declaring 'b' as type(t2) :: b = t2 (NULL(), NULL()) clears the valgrind fault but no finalization occurs. I notice that finalization does not occur if an entity has the save attribute. gfortran assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does not occur. I have been unable to find whether or not this is conforming. However, initializing 'b' in an assignment: b = t2(NULL(), NULL()) clears the valgrind fault and results in the deallocation of memory. This confirms my suspicion about the save attribute. In conclusion, I do not believe that this is a bug. If you do not use pointers as pointers, make them allocatable instead. These are automatically nullified on entry into scope. Thanks for the report by the way! Paul
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 --- Comment #3 from Paul Thomas --- Created attachment 49722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49722&action=edit Tentative patch for the PR The attached regtests OK and the following runs correctly: module ur contains function kn1() result(hm2) complex :: hm(1:2), hm2(1:2) data (hm(md)%re, md=1,2)/1.0, 2.0/ hm2 = hm end function kn1 function kn2() result(hm2) complex :: hm(1:2), hm2(1:2) data (hm(md)%im, md=1,2)/1.0, 2.0/ hm2 = hm end function kn2 end module ur use ur if (any (kn1() .ne. [(1.0,0.0),(2.0,0.0)])) stop 1 if (any (kn2() .ne. [(0.0,1.0),(0.0,2.0)])) stop 2 end I have yet to test inquiry references of derived type components. I suspect that a bit more work is needed. Watch this space Paul
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas --- Created attachment 49730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49730&action=edit Fix for the PR
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Paul Thomas changed: What|Removed |Added Last reconfirmed||2020-12-10 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- Blast! Finger slipped The fix regtests OK. I will commit as 'obvious' with a test case in the next day or two. Thanks for the report. Paul
[Bug fortran/35718] deallocating non-allocated pointer target does not fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718 Paul Thomas changed: What|Removed |Added Assignee|pault at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Paul Thomas --- (In reply to Thomas Koenig from comment #8) > We have an unsigned short in our descriptor that we can use > for keeping track of what we allocated and where. > > So, we have 16 bits. State we can keep around is: > > Type of descriptor: Allocatable, pointer, passed argument. 2 bits. > > Associated: No, allocated, target. 2 bits. > > Contiguous: 1 bit. > > Anything else we would need? That would still leave us 11 bit in reserve. Hi Thomas, That was the intention of the field in the descriptor. I just never got round to it. I have unassigned myself since I have a huge backlog of other issues. Cheers Paul
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #3 from Paul Thomas --- (In reply to Paul Thomas from comment #2) > > The fix regtests OK. I will commit as 'obvious' with a test case in the next > day or two. Cancel that, there is one regression. Paul
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas ---
Created attachment 49743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49743&action=edit
Fix for this PR and PR97723
This regtests and fixes both PRs
Paul
select_rank_5.f90:
! { dg-do run }
!
! Test the fixes for PR97723 and PR97694.
!
! Contributed by Martin
!
module mod
implicit none
private
public cssel
contains
function cssel(x) result(s)
character(len=:), allocatable :: s
class(*), dimension(..), optional, intent(in) :: x
if (present(x)) then
select rank (x)
rank (0)
s = '0' ! PR97723: ‘assign’ at (1) is not a function
! PR97694: ICE in trans-stmt.c(trans_associate_var)
rank (1)
s = '1' ! PR97723: ‘assign’ at (1) is not a function
rank default
s = '?' ! PR97723: ‘assign’ at (1) is not a function
end select
else
s = '-'
end if
end function cssel
end module mod
program classstar_rank
use mod
implicit none
integer :: x
real, dimension(1:3) :: y
logical, dimension(1:2,1:2) :: z
if (any ([cssel(x),cssel(y),cssel(z),cssel()] .ne. ['0','1','?','-'])) stop 1
end program classstar_rank
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- I guess that it's mine :-) Paul
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #4 from Paul Thomas --- Please see PR97694 for a patch that fixes both PRs at once. Paul
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 --- Comment #6 from Paul Thomas --- (In reply to kargl from comment #4) > (In reply to Paul Thomas from comment #3) > > > function kn1() result(hm2) > > complex :: hm(1:2), hm2(1:2) > > data (hm(md)%re, md=1,2)/1.0, 2.0/ > > hm2 = hm > > end function kn1 > > Are you sure that this is valid Fortran? I cannot > find anything in the Fortran standard that says hm%im > is defined. Thus, 'hm2=hm' is referencing a variable > that is no completely defined. > > > 19.6.1 Definition of objects and subobjects > > 2 Arrays, including sections, and variables of derived, character, > or complex type are objects that consist of zero or more subobjects. > Associations may be established between variables and subobjects and > between subobjects of different variables. These subobjects may become > defined or undefined. > > 5 A complex or character scalar object is defined if and only if all > of its subobjects are defined. Hi Steve, I saw your comment a bit too late. I think that you are correct. I guess that, at very least, I should not zero out the undefined part of the complex object? That way it would be equivalent to using assignment to achieve the same thing or to partially define a derived type. I'll post on clf. Cheers Paul
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 --- Comment #8 from Paul Thomas --- The example that you give shows that setting the undefined part to zero certainly is not correct. I updated my tree for the commit and am only just now rebuilding. It'll be tomorrow before I put this right. I guess that this is in the category of invalid but not forbidden. It's in the same category as: complex :: a, b a%im = 1.0 b = a print *, a, b end Thanks Paul
[Bug fortran/97045] A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045
--- Comment #2 from Paul Thomas ---
Created attachment 49272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49272&action=edit
Updated patch
It turned out that with the original patch, character payloads of the unlimited
polymorphic array were still not behaving properly - see the test below.
I am about to submit to the fortran list.
Thanks again
Paul
! { dg-do run }
!
! Test the fix for PR97045. The report was for the INTEGER version. Testing
! revealed a further bug with the character versions.
!
! Contributed by Igor Gayday
!
program test_prg
implicit none
integer :: i
integer, allocatable :: arr(:, :)
character(kind = 1, len = 2), allocatable :: chr(:, :)
character(kind = 4, len = 2), allocatable :: chr4(:, :)
arr = reshape ([(i, i = 1, 9)], [3, 3])
do i = 1, 3
call write_array(arr(1:2, i), i)
end do
chr = reshape([(char (i)//char (i+1), i = 65, 83, 2)], [3, 3])
do i = 1, 3
call write_array (chr(1:2, i), i)
end do
chr4 = reshape([(char (i, kind = 4)//char (i+1, kind = 4), i = 65, 83, 2)], &
[3, 3])
do i = 1, 3
call write_array (chr4(1:2, i), i)
end do
contains
subroutine write_array(array, j)
class(*), intent(in) :: array(:)
integer :: i = 2
integer :: j, k
select type (elem => array(i))
type is (integer)
k = 3*(j-1)+i
if (elem .ne. k) stop 1
type is (character(kind = 1, len = *))
k = 63 + 2*(3*(j-1)+i)
if (elem .ne. char (k)//char (k+1)) print *, elem, " ", char
(k)//char (k+1)
type is (character(kind = 4, len = *))
k = 63 + 2*(3*(j-1)+i)
if (elem .ne. char (k, kind = 4)//char (k+1, kind = 4)) stop 3
end select
end subroutine
end program
[Bug fortran/97209] New: TODO: building array references needs a big tidy up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97209 Bug ID: 97209 Summary: TODO: building array references needs a big tidy up Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- The fix for PR97045 flags up the need for rationalization of building array references in trans-array.c and trans.c. The patch works but the result has made this area of gfortran even more difficult to understand and to maintain. At present, I just do not have the bandwidth to do the job but have noted it for the future. If somebody else could take it on that would be great :-) Paul
[Bug fortran/97209] TODO: building array references needs a big tidy up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97209 Paul Thomas changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-05 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #1 from Paul Thomas --- Manifestly confirmed :-) Paul
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 --- Comment #9 from Paul Thomas --- Tobias's original suggestion is certainly more concise, although equivalent to the present code. I will commit the change today or tomorrow as obvious. It happens that I am working on trans-expr.c at the moment and so will have to reset my tree to deal with this. Regards Paul
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #11 from Paul Thomas --- Fixed after a mere 3542 days. Thanks for the report :-) Paul
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-17 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Googling on munmap_chunk(): invalid pointer reveals that this is quite a frequent problem. It originates from the call out = sel_rank(get_tuple(x)) rather than what happens in either function. Somewhere a free is bein done on memory that is not malloc'ed. Bizarrely, out = sel_rank([get_tuple(x)]) as does z = get_tuple(x) ! z appropriately declared of course! out = sel_rank(z) valgrind confirms this: snip ==535157== Invalid free() / delete / delete[] / realloc() ==535157==at 0x483A9F5: free (vg_replace_malloc.c:538) ==535157==by 0x40343A: MAIN__ (pr98342.f90:48) ==535157==by 0x4035BA: main (pr98342.f90:40) ==535157== Address 0x1ffeffede0 is on thread 1's stack ==535157== in frame #1, created by MAIN__ (pr98342.f90:39) ==535157== snip The problem arises somewhere in trans-expr.c(gfc_conv_procedure_call). I am on to it :-) Paul
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
--- Comment #3 from Paul Thomas ---
Created attachment 49793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49793&action=edit
Fix for the PR
This regtests OK. Testcase:
! { dg-do run }
!
! Test the fix for PR98342.
!
! Contributed by Martin Stein
!
module mod
implicit none
private
public get_tuple, sel_rank
! we need to encapsulate the allocatable in a derived type
type, public :: tuple
integer, dimension(:), allocatable :: t
! with pointer there is no failure
! integer, dimension(:), pointer :: t
end type tuple
contains
function sel_rank(x) result(s)
character(len=:), allocatable :: s
type(tuple), dimension(..), intent(in) :: x
select rank (x)
rank (0)
s = '0'
rank (1)
s = '1'
rank default
s = '?'
end select
! this is printed as expected
! print *, 'rank: ', s
end function sel_rank
function get_tuple(t) result(a)
type(tuple) :: a
integer, dimension(:), intent(in) :: t
allocate(a%t, source=t)
end function get_tuple
end module mod
program alloc_rank
use mod
implicit none
integer, dimension(1:3) :: x
character(len=:), allocatable :: output
type(tuple) :: z
x = [1,2,3]
! this should print '0' (as a tuple itself has rank 0)
output = sel_rank(get_tuple(x)) ! runtime: Error in `./alloc_rank.x':
! munmap_chunk(): invalid pointer
! (memory freed not malloc'ed)
if (output .ne. '0') stop 1
output = sel_rank([get_tuple(x)]) ! This worked OK
if (output .ne. '1') stop 2
deallocate(output)
end program alloc_rank
Paul
[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Created attachment 49794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49794&action=edit Fix for the PR This fixes the PR by effectively changing a=t() to a=t(NULL()). It even regtests! I need to check that this is correct when a default initializer is present for scalar, allocatable components. Watch this space! Paul
[Bug fortran/98408] Character lengths for allocatable character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98408
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #1 from Paul Thomas ---
Hi Thomas,
>From gfc_conv_intrinsic_sizeof:
if (arg->ts.type == BT_CHARACTER)
byte_size = size_of_string_in_bytes (arg->ts.kind,
argse.string_length);
else
{
if (arg->rank == 0)
byte_size = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
argse.expr));
else
byte_size = gfc_get_element_type (TREE_TYPE (argse.expr));
byte_size = fold_convert (gfc_array_index_type,
size_in_bytes (byte_size));
}
}
ie. characters are treated separately.
The problem is that gfc_get_element_type will come back with void* (or perhaps
void if TYPE_STRING_FLAG is not set) because of the cast in the allocation:
a.data = (void * restrict) __builtin_malloc (50);
which is what GFC_TYPE_ARRAY_DATAPTR_TYPE is coming back with.
I think that you will have to either interrogate the dtype for the element
length, use the span field or se->string_length if you know the kind.
Not so much a bug as a 'feature', I'm afraid.
Paul
[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Paul Thomas --- It is too late for 8-branch - sorry. Closing. Paul
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 --- Comment #9 from Paul Thomas --- (In reply to markeggleston from comment #8) > As noted by Tobias: > > Patch was submitted > at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html > but the new mailing had stripped off the 'text/x-patch' MIME type back > then. > > Is the patch going to be resubmitted? Mark & Tobias, Yes, it will be resubmitted today. Paul
[Bug fortran/96102] ICE in check_host_association, at fortran/resolve.c:5994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Paul Thomas --- I should have closed this one. I have too much of a backlog to be backporting non-regressions. Thanks for the report. Paul
[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96495 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Paul Thomas --- Since this is not a regression, I am closing. Thanks for the report Paul
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 --- Comment #7 from Paul Thomas --- (In reply to Martin Liška from comment #6) > (In reply to Paul Thomas from comment #5) > > (In reply to CVS Commits from comment #4) > > > The master branch has been updated by David Malcolm > > > : > > > > > > https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 > > > > > > commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 > > > Author: David Malcolm > > > Date: Wed Mar 4 12:10:34 2020 -0500 > > > > > > analyzer: add regression test for fixed ICE [PR94028] > > > > > > The C++ reproducer for PR analyzer/94028 generates a similar ICE > > > to that of the Fortran reproducer for PR analyzer/93993 and, like > > > it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. > > > > > > This patch adds the C++ reproducer as a regression test. > > > > > > gcc/testsuite/ChangeLog: > > > PR analyzer/94028 > > > * g++.dg/analyzer/pr94028.C: New test. > > > > FAIL: gfortran.dg/analyzer/pr93993.f90 -O (test for excess errors) > > Excess errors: > > /home/pault/gitsources/gcc/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21: > > 0: Warning: leak of 'tm' [CWE-401] [-Wanalyzer-malloc-leak] > > > > On current 10-branch. FC31/x86_64 > > > > Paul > > @David: The test-case is still failing. Are you planning to fix it or may I > mark it as xfail? Hi All, It is still failing on 10-branch. Cheers Paul
[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Paul Thomas --- Fixed on 9-11 branches. Thanks for the report Paul
[Bug fortran/96100] [9/10/11 Regression] ICE in gimplify_expr, at gimplify.c:14638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96100 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Paul Thomas --- Fixed on 9-11 branches. Thanks for the report Paul
[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Created attachment 49856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49856&action=edit Fix for the PR Thank you for the report on this problem. The attached patch fixes the problem and regression tests OK. I need to do a bit more thinking about it because I was unable to find a point in general expression simplification where the fix could be applied. Instead, it only seems to work in the simplification of intrinsic functions. Fortunately, this seems to be the only place where it is needed. Paul
[Bug fortran/98458] ICE in gfc_conv_array_initializer due to array expressions within implied do-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458 Paul Thomas changed: What|Removed |Added Summary|PRINT the array constructed |ICE in |from implied do-loop throw |gfc_conv_array_initializer |ICE |due to array expressions ||within implied do-loop --- Comment #7 from Paul Thomas --- (In reply to Steve Kargl from comment #6) Hi Steve, I didn't check for any new postings when I attached my version of the patch. Apologies for treading on your toes again :-) > PRINT has nothing to do with the problem. I simply > have no interest in fixing the changed and now misleading > subject line. I've been asked to stop. Who asked you to stop? Anyway, I have added a slightly more informative subject line. > > My proposed patch fixes the issue in one spot. Paul's > patch fixes potentially many spots. Unfortunately, the > handling of implied do-loops is done in an ad hoc fashion, > and is complicated by the potential problem of exhausting > the stack. I like your use of gfc_reduce_init_expr since it also does a type check. Note though that it resets gfc_reduce_init_expr and so it needs to be set once again after the call. I had totally forgotten about the 'fatal' flag needing to be set in the call to gfc_expand_constructor to avoid stack exhaustion. I had to rediscover it experimentally. A combined patch is being regtested now. Cheers Paul
[Bug fortran/93794] [8/9/10/11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 --- Comment #6 from Paul Thomas --- (In reply to anlauf from comment #5) > > Paul, > > > > are you still working on this? > > Paul, > > this is still one of yours... Hi Harald, Hah! I am probably a week or two from getting to it. I have been working my way through a backlog but have been held up for some days by unlimited polymorphic issues: see https://groups.google.com/u/1/g/comp.lang.fortran/c/Ybasfal3YC4 I will be posting a interpretation query today. If you want to take this over, please do so. Please let me know because I have put it in my active PRs spreadsheet. Happy New Year to both of you Paul
[Bug fortran/98498] New: Interp request: defined operators and unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Bug ID: 98498
Summary: Interp request: defined operators and unlimited
polymorphic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
It looks as if gfortran is standard defying;
J3/yy-nnn
To: J3 Members
From: Steve Lionel
Subject: F2018 interp: Extending intrinsic operator with class(*) dummies
Date: 01-Jan-2021
--
NUMBER: F08/! /interp assigns number after submission
TITLE: Extending intrinsic operator with class(*) dummies
KEYWORDS: unlimited polymorphic, defined operator, intrinsic operator
DEFECT TYPE:! /interp assigns
STATUS: J3 consideration in progress
QUESTION:
Consider the following program (created by Paul Richard Thomas):
MODULE mytypes
IMPLICIT none
TYPE pvar
character(len=20) :: name
integer :: level
end TYPE pvar
interface operator (==)
module procedure pvar_eq
end interface
contains
function pvar_eq(a,b)
implicit none
class(*), intent(in) ::a,b
logical ::pvar_eq
if (.not. same_type_as (a, b)) then
pvar_eq = .false.
return
end if
select type (a)
type is (pvar)
select type (b)
type is (pvar)
print *, "a & b are type pvar"
if((a%level.eq. b%level) .and. (a%name .eq. b%name)) then !A
pvar_eq = .true.
else
pvar_eq = .false.
end if
end select
class default
print *, "class default: returning false"
pvar_eq = .false.
end select
end function pvar_eq
end MODULE mytypes
program test_eq
use mytypes
implicit none
type(pvar) x, y
x = pvar('test 1', 100)
y = pvar('test 1', 100)
write(*, *) x == y
x = pvar('test 1', 100)
y = pvar('test 2', 100)
write(*, *) x == y
end program test_eq
The intrinsic equality operator is extended with a function where both
dummy arguments are unlimited polymorphic. Three compilers accept this;
two use the extension for comparisons of any type, such as the one between
two integers at "!A" - the other applies the intrinsic meaning to the
integer comparison.
15.4.3.4.2p1 (Defined operation) says:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the types, kind type parameters, or ranks of the dummy arguments
shall differ from those required for the intrinsic operation (10.1.5)."
The phrase "shall differ" here is not the same as in 15.4.3.4.5
(Restrictions on generic declarations) which instead talks about TKR
compatibility and the ability to "distinguish" dummy arguments.
"C1511 Within the scope of a generic operator, if two procedures with
that identifier have the same number of arguments, one shall have a
dummy argument that corresponds by position in the argument list to a
dummy argument of the other that is distinguishable from it."
Was it intended that the standard treat extending intrinsic operators in
a different manner than other generic interfaces? If so, how should this
program be interpreted?
ANSWER:
No, such a treatment was not intended. Extending a generic intrinsic
operator follows the same rules as other generic extensions. The
example program violates C1511 in that the unlimited polymorphic
dummy arguments are not distinguishable from arguments of any type
for which the intrinsic operator is valid (Table 10.2). Consider also
Note 1 in 10.1.6.1 (Defined Operations > Definitions) says:
"An intrinsic operator can be used as the operator in a defined operation.
In such a case, the generic properties of the operator are extended"
An edit is proposed to correct the deficiency.
EDITS to 18-007r1:
[295:10, 15.4.3.4.2 (Defined operations)]
In the last sentence, remove the text "types, kind type parameters, or
ranks of the" and replace "replace "differ from" with "be distinguishable
from", with "distinguishable" linked to 15.4.3.4.5 (Restrictions on
generic declarations). The sentence now reads:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the dummy arguments shall be distinguishable from those required
for the intrinsic operation (10.1.5)."
SUBMITTED BY: Steve Lionel
HISTORY: yy-nnnm223 F08/ submitted
--
[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498 Paul Thomas changed: What|Removed |Added Last reconfirmed||2021-01-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #1 from Paul Thomas ---
Created attachment 49869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49869&action=edit
Fix pending the iterpretation request
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! gfortran.dg/interface_49.f90
! Tests the fix for PR98498 in which the '==' operator interface was not
! applied to intrinsic type/kind expressions. This meant that the
! interface was not applied to the .eq. expressions in 'star_eq' even
! though the unlimited polymorphic dummies are type compatible with all
! entities. The tree dump used to contain 10 'star_eq's.
!
! Note that overridding intrinsic operators with functions that have
! compliant intrinsic dummies still yields the error "Operator interface
! at (1) conflicts with intrinsic interface", as required by
! F2003(12.3.2.1.1).
!
! Contributed by Paul Thomas
!
MODULE mytypes
IMPLICIT none
TYPE pvar
character(len=20) :: name
integer :: level
end TYPE pvar
interface operator (==)
module procedure star_eq
end interface
contains
RECURSIVE function star_eq(a,b) ! The recursive attribute should not be
required.
implicit none
class(*), intent(in) ::a,b
logical ::star_eq
if (.not. same_type_as (a, b)) then
star_eq = .false.
return
end if
select type (a)
type is (pvar)
select type (b)
type is (pvar)
print *, "a & b are type pvar"
if((a%level.eq. b%level) .and. (a%name .eq. b%name)) then
star_eq = .true.
else
star_eq = .false.
end if
end select
class default
print *, "class default: returning false"
star_eq = .false.
end select
end function star_eq
end MODULE mytypes
program test_eq
use mytypes
implicit none
type(pvar) x, y
x = pvar('test 1', 100)
y = pvar('test 1', 100)
write(*, *) x == y
x = pvar('test 1', 100)
y = pvar('test 2', 100)
write(*, *) x == y
end program test_eq
! { dg-final { scan-tree-dump-times "star_eq" 12 "original" } }
[Bug fortran/94246] [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Paul Thomas --- Fixed on 9-, 10- and 11- branches. Thanks for the reports. Paul
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 94246, which changed state. Bug 94246 Summary: [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #27 from Paul Thomas --- Created attachment 49875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49875&action=edit Fix for the cases in comments 23 and 24 Hi Damian, Happy New Year! or I wish you a better one anyway. I have been doing a bit of catching up. The original patch for this PR is now applied as far back as I want to go. The new attachment fixes the testcases in comments 23 and 24. It even regtests OK. Thanks for your patience. Paul
[Bug fortran/98458] ICE in gfc_conv_array_initializer due to array expressions within implied do-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458 --- Comment #9 from Paul Thomas --- Created attachment 49883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49883&action=edit Updated versionof the patch I have rolled in Steve's use of gfc_reduce_init_expr and will submit within the hour. Best regards Paul
[Bug fortran/98534] New: Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 Bug ID: 98534 Summary: Intrinsic functions failing with unlimited polymorphic actual arguments Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: pault at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 49891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49891&action=edit Provisional patch Unlimited polymorphic actual arguments to 'storage_size' and 'transfer' fail, when the dynamic type is character. This comes about because the '_len' field is not used. The attached is a partial, provisional patch. I have not checked other intrinsics yet. It should also be noted that 'same_type_as' still uses the '_hash' field of the vptr, rather than its address. This is known to fail in some cases. A testcase can be found below. Paul ! No errors with character(*), parameter :: string = "abcdefgh" class(*), allocatable :: star character(len=:), allocatable :: chr integer :: sz, sum1, sum2 ! Part 1: works correctly star = 1.0 sz = storage_size (star)/8 allocate (character(len=sz) :: chr) chr = transfer (star, chr) sum1 = sum ([(ichar(chr(i:i)), i = 1, sz)]) chr = transfer(1.0, chr) sum2 = sum ([(ichar(chr(i:i)), i = 1, sz)]) if (sz /= kind (1.0)) stop 1 if (sum1 /= sum2) stop 2 deallocate (star) ! The automatic reallocation causes invalid writes ! and memory leaks. Even with this deallocation ! The invalid writes still occur. deallocate (chr) ! Part 2: gets everything from because '_len' field of 'star' not used star = string sz = storage_size (star)/8 if (sz /= len (string)) print *, "stop 3" ! storage_size fails sz = len (string) ! Ignore previous error in storage_size allocate (character(len=sz) :: chr) chr = transfer (star, chr) sum1 = sum ([(ichar(chr(i:i)), i = 1, sz)]) chr = transfer(string, chr) sum2 = sum ([(ichar(chr(i:i)), i = 1, sz)]) if (sum1 /= sum2) print *, "stop 4" ! transfer fails deallocate (star, chr) end
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #44 from Paul Thomas --- Closed on 9- thru' 11-branches. Thanks for the report. Paul
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Paul Thomas --- Closed on 9- thru' 11-branches. Thanks for the report and sorry for the belated fix. Paul
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 --- Comment #8 from Paul Thomas --- (In reply to José Rui Faustino de Sousa from comment #7) > Hi all! > > Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds > > Best regards, > José Rui Yes, indeed. This with those compile options module m type s class(*), allocatable :: a[:]! This ICEd end type end gives ../pr91726/pr91726.f90:5:3: 5 | end | ^ Error: mismatching comparison operand types integer(kind=8) unsigned long if (_10 != 1) goto ; else goto ; ../pr91726/pr91726.f90:5:3: internal compiler error: ‘verify_gimple’ failed 0xec247d verify_gimple_in_seq(gimple*) ../../gcc/gcc/tree-cfg.c:5119 The problem appears to lie in the bounds checking in trans-expr.c(gfc_copy_class_to_class) at line 1425 in master. It is produced by the vtable _copy function. For some reason that I cannot see from the code, 10-branch compiles this snippet just fine, while 9-branch produces a completely different error. It's now in my spreadsheet as an intersting one! Paul
[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 49936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49936&action=edit Initial fix for the PR Triggered by a recent thread on clf, I have made a first stab at this PR. This patch is thus far perfect and has the following regressions: FAIL: gfortran.dg/class_optional_1.f90 -O0 execution test FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O1 execution test FAIL: gfortran.dg/finalize_15.f90 -O0 (internal compiler error) FAIL: gfortran.dg/finalize_25.f90 -O0 execution test FAIL: gfortran.dg/finalize_29.f08 -O0 execution test plus FAIL: gfortran.dg/prof/dynamic_dispatch_6.f03 execution,-fprofile-generate -D_PROFILE_GENERATE which is not too bad for a first attempt. Note that for arrays, finalization is occurring before reallocation of the lhs contrary to the requirements of the standard. This test, based on the reporter's testcase, works as intended: module testmode implicit none type :: simple integer :: ind contains final :: destruct1, destruct2 end type simple integer :: check_scalar integer :: check_array(2) integer :: final_count = 0 contains subroutine destruct1(self) type(simple), intent(inout) :: self !print *, "DESTRUCTING SCALAR", self%ind check_scalar = self%ind check_array = 0 final_count = final_count + 1 end subroutine destruct1 subroutine destruct2(self) type(simple), intent(inout) :: self(:) !print *, "DESTRUCTING ARRAY", self%ind check_scalar = 0 check_array = self%ind final_count = final_count + 1 end subroutine destruct2 subroutine test (cnt, scalar, array, off) integer :: cnt integer :: scalar integer :: array(:) integer :: off if (final_count .ne. cnt) stop 1 + off if (check_scalar .ne. scalar) stop 2 + off if (any (check_array .ne. array)) stop 3 + off end subroutine test end module testmode program test_final use testmode implicit none type(simple), allocatable :: myres, myres2 type(simple), allocatable :: myarray(:) type(simple) :: thyres = simple(21), thyres2 = simple(22) allocate(myres) allocate(myres2) myres%ind = 1 myres2%ind = 2 myres = myres2 call test(1, 1, [0,0], 10) allocate(myarray(2)) myarray%ind = [42, 43] myarray = [thyres, thyres2] call test(2, 0, [42,43], 20) thyres2 = simple(99) call test(3, 22, [0,0], 30) thyres = thyres2 call test(4, 21, [0,0], 40) deallocate (myres, myres2) call test(6, 2, [0,0], 100) deallocate (myarray) call test(7, 0, [21,22], 200) end program test_final Paul
[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 --- Comment #3 from Paul Thomas --- Created attachment 49952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49952&action=edit Slightly better patch This gets rid of the regression in gfortran.dg/finalize_29.f08. However, finalize_25.f90 exposes the real scale of the problem because it shows that finalization is partially implemented for variables with allocatable components and this causes collisions with the finalization in the patch. Cheers Paul
[Bug fortran/98573] Dynamic type lost on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98573 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- Created attachment 50023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50023&action=edit Fix for all three tests I believe that attached does the job although I don't quite see as many failing cases as you. It regtests too :-) I will investigate a bit further before I submit. Thanks for the report. Paul
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas ---
Created attachment 50036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50036&action=edit
Fix for the PR
Dear Yves,
I will be committing this patch to master this evening, after it has completed
regression testing, together with the testcase below. I will apply to 9- and
10-branches in a few weeks time.
You will note that I have made the components public so that I do not need to
write constructors.
Many thanks for the report. I hope that the fix will help your work in support
of sustainable development in Amazonia, even if in an insignificant way.
Regards
Paul
! { dg-do run }
!
! associated_target_7.f90: Test the fix for PR98565.
!
! Contributed by Yves Secretan
!
MODULE PS_SN0N_M
IMPLICIT NONE
PRIVATE
TYPE, PUBLIC :: DT_GRID_T
INTEGER :: NNT
CONTAINS
! PASS
END TYPE DT_GRID_T
TYPE, PUBLIC :: LM_ELEM_T
CLASS(DT_GRID_T), POINTER :: PGRID
CONTAINS
PROCEDURE, PUBLIC :: REQPGRID => LM_ELEM_REGPGRID
END TYPE LM_ELEM_T
TYPE, PUBLIC :: PS_SN0N_T
CLASS(DT_GRID_T), POINTER :: PGRID
CONTAINS
PROCEDURE, PUBLIC :: ASGOELE => PS_SN0N_ASGOELE
END TYPE PS_SN0N_T
CONTAINS
!
!
FUNCTION LM_ELEM_REGPGRID(SELF) RESULT(PGRID)
CLASS(DT_GRID_T), POINTER :: PGRID
CLASS(LM_ELEM_T), INTENT(IN) :: SELF
PGRID => SELF%PGRID
RETURN
END FUNCTION LM_ELEM_REGPGRID
!
!
FUNCTION PS_SN0N_ASGOELE(SELF, OELE) RESULT(ERMSG)
INTEGER :: ERMSG
CLASS(PS_SN0N_T), INTENT(IN) :: SELF
CLASS(LM_ELEM_T), INTENT(IN) :: OELE
!CLASS(DT_GRID_T), POINTER :: PGRID
LOGICAL :: ISOK
!
! ASSOCIATED with temp variable compiles
!PGRID => OELE%REQPGRID()
!ISOK = ASSOCIATED(SELF%PGRID, PGRID)
! ASSOCIATE without temp variable crashes with ICE
ISOK = ASSOCIATED(SELF%PGRID, OELE%REQPGRID())
ERMSG = 0
IF (ISOK) ERMSG = 1
RETURN
END FUNCTION PS_SN0N_ASGOELE
END MODULE PS_SN0N_M
USE PS_SN0N_M
CLASS(PS_SN0N_T), ALLOCATABLE :: SELF
CLASS(LM_ELEM_T), ALLOCATABLE :: OELE
TYPE (DT_GRID_T), TARGET :: GRID1 = DT_GRID_T (42)
TYPE (DT_GRID_T), TARGET :: GRID2 = DT_GRID_T (84)
ALLOCATE (PS_SN0N_T :: SELF)
ALLOCATE (LM_ELEM_T :: OELE)
SELF%PGRID => GRID1
OELE%PGRID => NULL ()
IF (SELF%ASGOELE (OELE) .NE. 0) STOP 1
OELE%PGRID => GRID2
IF (SELF%ASGOELE (OELE) .NE. 0) STOP 2
OELE%PGRID => GRID1
IF (SELF%ASGOELE (OELE) .NE. 1) STOP 3
END
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Paul Thomas --- Fixed on 9-, 10- and 11-branches. Thanks for the report. Paul
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Paul Thomas --- Closed as blindingly obvious on 9-, 10- and 11-branches. Thanks for the fix, Steve. Paul
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #8 from Paul Thomas ---
(In reply to Steve Kargl from comment #7)
> On Sat, Jan 02, 2021 at 04:12:27AM +, jvdelisle at charter dot net wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
> >
> > --- Comment #5 from Jerry DeLisle ---
> > Patch regresses several test cases.
> >
>
> This regresses okay.
>
> diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
> index 14361a10f68..b860f7eaa26 100644
> --- a/gcc/fortran/trans-expr.c
> +++ b/gcc/fortran/trans-expr.c
> @@ -2537,7 +2537,9 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int
> kind,
>if (!CONSTANT_CLASS_P (tmp) && !DECL_P (tmp))
> end.expr = gfc_evaluate_now (end.expr, &se->pre);
>
> - if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> + if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> + && (ref->u.ss.start->symtree
> + && !ref->u.ss.start->symtree->n.sym->attr.implied_index))
> {
>tree nonempty = fold_build2_loc (input_location, LE_EXPR,
>
> My test program without the dejagnu stuff.
>
> program test
>
>implicit none
>
>call sub('Lorem ipsum')
>
>contains
>
> subroutine sub( text )
> character(len=*), intent(in) :: text
> character(len=1), allocatable ::c(:)
> integer :: i
> c = [ ( text(i:i), i = 1, len(text) ) ]
> if (c(1) /= 'L') stop 1
> end subroutine sub
>
> end program test
Hi Steve and Jerry,
This is OK to commit to master. I would suggest cherry-picking to 9- and
10-branches too.
Cheers
Paul
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- This is a case of a gcc_assert too many. Deleting the following cures the problem: if (ss_expr != expr) /* Elemental function. */ gcc_assert ((expr->value.function.esym != NULL && expr->value.function.esym->attr.elemental) || (expr->value.function.isym != NULL && expr->value.function.isym->elemental) || gfc_inline_intrinsic_function_p (expr)); else gcc_assert (ss_type == GFC_SS_INTRINSIC); The preceeding if statement, has if (ss_expr != expr || ss_type != GFC_SS_FUNCTION) so the second assert is redundant. I am disinclined to add any more clauses to the first :-) This change regtests OK. However adding: || (gfc_expr_attr (expr).proc_pointer && gfc_expr_attr (expr).elemental) does the job and regtests too. Paul
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #9 from Paul Thomas --- Created attachment 50057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50057&action=edit Patch that "fixes" all versions of the problem The attached patch has a fragment of my finalize on assignment patch in the second chunk. The changes are small and few so could be applied manually. Whatever is the legality or otherwise, this fixes all versions of the problem and regtests OK. Please do what you will with this. If it is still open in a few weeks time, I will take it. At the present, I have too many open PRs. Paul
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #10 from Paul Thomas --- (In reply to Paul Thomas from comment #9) > Created attachment 50057 [details] > Patch that "fixes" all versions of the problem > > The attached patch has a fragment of my finalize on assignment patch in the > second chunk. The changes are small and few so could be applied manually. > > Whatever is the legality or otherwise, this fixes all versions of the > problem and regtests OK. > > Please do what you will with this. If it is still open in a few weeks time, > I will take it. At the present, I have too many open PRs. > > Paul Final remarks for the time being in comments below: module cs implicit none private public classStar_map_ifc public apply, selector integer, target :: integer_target abstract interface function classStar_map_ifc(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x end function classStar_map_ifc end interface contains function fun(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x select type (x) type is (integer) integer_target = x ! One way of overcoming dangling target business y => integer_target class default y => null() end select end function fun function apply(f, x) result(y) procedure(classStar_map_ifc) :: f integer, intent(in) :: x integer :: y class(*), pointer :: p y = 0 ! Get rid of 'y' undefined warning p => f(x) select type (p) type is (integer) y = p end select end function apply function selector() result(f) procedure(classStar_map_ifc), pointer :: f f => fun end function selector end module cs program classStar_map use cs implicit none integer :: x, y procedure(classStar_map_ifc), pointer :: f x = 123654 f => selector() ! Fixed by second chunk in patch (suppresses class assignment) y = apply(f, x) ! Fixed by first chunk in patch (passing procedure) print *, x, y end program classStar_map
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #11 from Paul Thomas --- Ah, go on! It's on my tree - I'll commit as obvious. Paul
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- Ah, go on! It's on my tree - I'll commit as obvious. Paul
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Paul Thomas --- Fixed on all three branches. Thanks for the report. Paul
[Bug fortran/91862] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91862 Paul Thomas changed: What|Removed |Added Status|WAITING |REOPENED Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- (In reply to Tobias Burnus from comment #6) > (In reply to anlauf from comment #5) > > With r11-6917, I do not get any failures for the testcases in this PR. > [...] > > z2.f90 works with 9.3.1, 10.2.1, and master. > > > Does anybody know when this was fixed? Close the PR, add a testcase? > > It fails here with gcc-9 (of Ubuntu) which was updated on 08 Aug 2020. Only > glancing at the GCC 9 log files: > > I think the patch > https://gcc.gnu.org/g:9db58db5b3986531475968dd383f13a3f925d7ae for PR 96100 > and PR 96101 fixes the issue, but I did not do any regression testing. The patch for PRs 96100/101 was backported to 9-branch on 28th December. Both testcases run fine with 9-branch now. They even give the intended result :-) Before closing, I will add a testcase to master. I have taken the PR and reopened it. Cheers Paul
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #12 from Paul Thomas --- (In reply to Tobias Burnus from comment #11) > Related / same issue: > https://gcc.gnu.org/pipermail/fortran/2021-January/055654.html Hi Tobias, Over the weekend, I had a stab at fixing this recent issue. I can fix this but at the risk of increasing the problem of leaks in the original examples in this PR and causing some regressions. I am going to make the testcase for PR98342 leak free so that the the specific problems are separated. Cheers Paul
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-02-02 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Paul Thomas --- Created attachment 50114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50114&action=edit Patch for the PR The attached regtests too :-) Thanks for the report, Damian. Paul
[Bug fortran/91862] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91862 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Paul Thomas --- Closed. Thanks for the report Gerhard! Paul
[Bug fortran/99065] New: ASSOCIATE function selector expression "no IMPLICIT type" failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99065 Bug ID: 99065 Summary: ASSOCIATE function selector expression "no IMPLICIT type" failure Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 50164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50164&action=edit Testcase illustrating the failure This bug was detected in testing variations of the testcase in PR98897. The attached fails with: ../pr98897/foo1.f90:9:20: 9 | print *, var%i |1 Error: Symbol ‘var’ at (1) has no IMPLICIT type If the contained procedures 'foo' and 'bar' are interchanged it compiles and produces the intended result. All component references suffer from this problem. Intrinsic types are fixed up by parse.c(gfc_fixup_sibling_symbols) but there is no simple way to do this for derived type or class selectors. Certain operator expressions also suffer from this problem. It is caused by parsing and matching in gfortran being single pass. This means that unless the specification of 'bar', in this case, has been obtained, the type of 'var' cannot be determined and primary.c(gfc_match_varspec) is bound to return MATCH_NO. I am looking at either two passes for contained procedures (specification blocks first, followed by code blocks) or a fixup in gfc_match_varspec that looks through the derived types for successful matches. Paul
[Bug fortran/99060] [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Thanks to all for the report, the fix and identification of the guilty. Clearly it is mine. I will do the honours on all three branches as 'obvious'. Paul
[Bug fortran/99060] [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Fixed on all three branches. Once again, thanks for the report, Gerhard, and for the fix, Steve. Steve, I realise that I didn't give you credit in the ChangeLogs. I will look up how this is done according to git-police rules and will make sure that it happens next time. Paul
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Paul Thomas --- Fixed on 10- and 11-branches. Thanks for the report, Damian. Paul PS See PR99065 for the reason for the delay.
[Bug fortran/99112] [11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 50219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50219&action=edit Patch for the PR In tackling the problem in gfc_conv_intrinsic_size, I noticed that there is similar code in gfc_conv_procedure_call that is plain and simple wrong. I have fixed both but, in the example, the incidental fix over-rides the intended one :-) For whatever reason, the chunk in gfc_conv_intrinsic_size doesn't quite work correctly because the wrong message is selected. Thus a bit more work is required Cheers Paul
[Bug fortran/99125] [9/10/11 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 50229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50229&action=edit Provisional patch This regtests OK but needs a small amount of reorganisation before submission. It willl happen tomorrow. BTW Although the ICE is a regression, the testcase never gave the intended result. What was the reason for the (7:8) in the testcase? -fcheck=all picks it up correctly. Cheers Paul
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 --- Comment #3 from Paul Thomas --- (In reply to Tobias Burnus from comment #2) > Confirmed – with 'class(*), allocatable :: f(:)' it should be valid (with > prior assignment). > > The problem is in gfc_match_rvalue: > > 3737 if (sym->ts.type == BT_CLASS && sym->attr.class_ok > 3738 && CLASS_DATA (sym)->as) > > without submodules, we have: > sym->ts.u.derived->components->as > which is working (and either NULL in the original example or != NULL with my > modification). > > However, with submodules, > sym->ts.u.derived->components > is NULL, i.e. 'sym->ts.u.derived' (name = "STAR") does not have any > scomponents, but it should have two, _data and _vptr! Hi Tobias, Is the problem not that the parser is not picking up the incorrectly placed print statement? It should never be passed to the matcher because it is in the contains context. It also should said that it has everything to do with module procedures and nothing to do with submodules. This has the same error sequence: module m interface module function f(x) integer, intent(in) :: x class(*), allocatable :: f end end interface contains module function f(x) integer, intent(in) :: x class(*), allocatable :: f end function print *, f(3) end I suspect that the end function is not popping the level. Cheers Paul
[Bug fortran/99124] [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124 --- Comment #5 from Paul Thomas --- Fixed on all three branches. Thanks for the report. I hope that the constraint on class-valued elemental functions doesn't spoil any code. Cheers Paul
[Bug fortran/99124] [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- It helps to mark it as fixed :-)
[Bug fortran/99819] [9/10/11/12 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 50735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50735&action=edit Experimenta "fix" for the PR The problem lies in class.c(gfc_build_class_symbol). The attachment contains two different experiments to test the hypothesis that the array_spec for 'y' is applied to the _data field of the derived type, which is then promoted to the main namespace. Subsequently, it is picked up in the declaration of 'z', which cause the problem. The first chunk, used by itself, turns the array_spec into a deferred array. The extent information is lost but the testcase now compiles and runs (incorrectly!). The second chunk, again by itself, puts the derived type representation in the function namespace. This now runs the testcase correctly and does the right thing. However, it can only encompass one such dummy. I'm onto it:-) Paul program p type t integer :: i end type class(t), allocatable :: dum1(:), dum2(:) allocate (t :: dum1(3), dum2(10)) dum2%i = [1,2,3,4,5,6,7,8,9,10] print *, f(dum1, dum2), g(dum1) contains function g(z) class(*) :: z(:) type(t) :: u(size(z)) g = 0 end function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) print *, size(y) select type (y) type is (t) f = 1 if (any (y%i .ne. [1,2,3])) print *, size(y%i) class default f = 0 end select end end
[Bug c++/46691] Null pointer in template deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- (In reply to CVS Commits from comment #2) > The master branch has been updated by Paul Thomas : > Apologies for the noise : This should have been PR46991. Paul
[Bug fortran/109066] Segfault when using defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 Paul Thomas changed: What|Removed |Added Last reconfirmed||2023-03-09 CC||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Version|unknown |13.0 Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- 8.3.1 20191027 runs through to the end of the program and then segfaults. 9.2.1 20191221 shows the same behaviour as mainline, as do all the branches in between. Thanks for the report Paul
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Paul Thomas changed: What|Removed |Added Resolution|DUPLICATE |INVALID CC||pault at gcc dot gnu.org Known to work|12.2.0 | Keywords||needs-bisection --- Comment #10 from Paul Thomas --- See comment at rnflow.f90:899 - As Richard Biener suggested to the list -fdefault-integer-8 fixes the problem but breaks tfft2 of the polyhedron suite. Better is: integer(8), parameter :: jmul = 843314861 ! multiplicateur integer(8), parameter :: jadd = 453816693 ! constante additive Cheers Paul
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Paul Thomas changed: What|Removed |Added Keywords||needs-bisection --- Comment #11 from Paul Thomas --- As a final remark from me, rnflow is not hanging but, rather, execution time becomes quadratic in ndonm (in rnprfm.h) and is already tiresomely long at a value of 40, compared with the default 101. Cheers Paul
